Cisco IOS Service Selection Gateway Configuration Guide, Release 12.4

Cisco IOS Service Selection Gateway
Configuration Guide
Release 12.4
Corporate Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100
Customer Order Number: DOC-7817497=

Text Part Number: 78-17497-01
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT
SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE
OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public
domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH
ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO
OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
CCSP, CCVP, the Cisco Square Bridge logo, Follow Me Browsing, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work,
Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP,
CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital,
the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare, GigaDrive, GigaStack, HomeLink,
Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, Linksys, MeetingPlace, MGX, the Networkers logo,
Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet,
The Fastest Way to Increase Your Internet Quotient, and TransPath 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. (0601R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the
document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
Cisco IOS Service Selection Gateway Configuration Guide

© 2005–2006 Cisco Systems, Inc. All rights reserved.
CONTENTS
About Cisco IOS Software Documentation for Release 12.4 xix
Documentation Objectives xix
Audience xix
Documentation Organization for Cisco IOS Release 12.4 xx
Document Conventions xxvi
Obtaining Documentation xxvii

Cisco.com xxvii
Product Documentation DVD xxviii
Ordering Documentation xxviii
Documentation Feedback xxviii
Cisco Product Security Overview xxix

Reporting Security Problems in Cisco Products xxix
Obtaining Technical Assistance xxx

Cisco Technical Support & Documentation Website xxx
Submitting a Service Request xxx
Definitions of Service Request Severity xxxi
Obtaining Additional Publications and Information xxxi
Using Cisco IOS Software for Release 12.4 xxxiii
Understanding Command Modes xxxiii
Getting Help xxxiv

Example: How to Find Command Options xxxv
Using the no and default Forms of Commands xxxviii
Saving Configuration Changes xxxviii
Filtering Output from the show and more Commands xxxix
Finding Additional Feature Support Information xxxix
Service Selection Gateway Features Roadmap 1
Overview of SSG 7
Contents 7
Prerequisites for SSG 7
Restrictions for SSG 7
Information About SSG 8

iii
Contents
Overview of Cisco’s Subscriber Edge Services Solution 8

Benefits of Using SSG 9
Components of a Subscriber Edge Services Solution 10
SSG 11
SESM 11
AAA Server 11
Services 11
Subscriber Edge Services Network Architecture 12
How Does SSG Work? 13
SSG Network Deployments 13
SSG Supported Access Protocols 13
Where to Go Next 14
Additional References 14
Related Documents 15
Technical Assistance 15
Implementing SSG: Initial Tasks 17
Contents 17
Prerequisites for Implementing SSG 17
Restrictions for Implementing SSG 18
How to Establish Initial SSG Communication 18

Enabling SSG 18
SSG and Cisco Express Forwarding 18
System Resource Cleanup When SSG Is Unconfigured 19
Configuring SSG Interface Direction 19
Interface Direction 20
Uplink Interface Redundancy Overview 20
Downlink Interface Redundancy Overview 20
SSG Uplink Interface Redundancy Topologies 21
Restrictions 22
Setting SSG Interface Direction for an Individual Interface 23
Setting the Direction on an ATM Subinterface (with PVC or PVC Range) 23
Verifying SSG Interface Binding 25
Configuring the Default Network 25
Processing of Default Network Traffic 26
Configuring SSG-SESM API Communication 26
Configuring SSG Port-Bundle Host-Key Functionality 27
Port-Bundle Host-Key Mechanism 28
Port-Bundle Length 28

iv
Contents
Benefits of SSG Port-Bundle Host-Key 29

Prerequisites for SSG Port-Bundle Host-Key 30
Restrictions for SSG Port-Bundle Host-Key 30
Configuring the SSG Port-Bundle Host-Key 30
Verifying SSG Port-Bundle Host-Key Configuration 32
Configuring SSG to AAA Server Interaction 33
Prerequisites 33
Monitoring and Maintaining Initial SSG Communication 33
Troubleshooting Initial SSG Communication 35
Configuration Examples for Establishing Initial SSG Communication 35
SSG Interface Direction: Examples 36
SSG Interface Redundancy: Examples 36
SSG Port-Bundle Host-Key Configuration: Example 37
SSG and AAA Server Interaction Configuration: Example 37
Establishing Initial SSG Communication: Example 38
Where To Go Next 39
MIBs 40
Feature Information for Implementing SSG 40
Configuring SSG to Serve as a RADIUS Proxy 43
Contents 43
Prerequisites for SSG RADIUS Proxy 43
Restrictions for SSG RADIUS Proxy 44

Information About SSG Authentication Using RADIUS Proxy 44
SSG AutoLogon Using RADIUS Proxy 44
RADIUS Server Redundancy 45
Broadcast of Host Accounting 45
RADIUS Client Subnet Definition 45
Host Route Insertion 45
Types of Deployments that Use SSG RADIUS Proxy 46
How to Configure SSG RADIUS Proxy 46
Configuring SSG Autologon Using RADIUS Proxy 46
Enabling SSG Autologon Using RADIUS Proxy 46
Configuring Session Identification Attributes 48
Configuring Timers for RADIUS Proxy 49
Configuring Multiple RADIUS Server Support 51

v
Contents
Configuring SSG RADIUS Proxy for GPRS Networks 53

Prerequisites 53
Overview of SSG RADIUS Proxy in GPRS Networks 54
IP Addresses Assignment in GPRS Networks that Use SSG RADIUS Proxy 54
Support For Overlapped Host IP Addresses 54
Forwarding of Accounting Packets 55
Session Identification by IP address 55
Per-PDP Accounting in GPRS Networks that Use SSG RADIUS Proxy 55
Configuring SSG RADIUS Proxy for CDMA2000 Deployments 55
Prerequisites 56
Restrictions 56
CDMA 57
SSG RADIUS Proxy for CDMA2000 Overview 57
SSG RADIUS Proxy for CDMA2000 for Simple IP 58
SSG RADIUS Proxy for CDMA2000 for Mobile IP 59
Dynamic Home Agent Assignment 59
Benefits of SSG RADIUS Proxy for CDMA2000 60
Configuring Home Agent IP Addresses 60
Verifying SSG RADIUS Proxy for CDMA2000 61
Configuring SSG RADIUS Proxy for 802.1x WLAN Deployments 62
Prerequisites 63
EAP Implementations Supported by SSG 63
SSG EAP Environment 63
EAP Transparency 64
Prevention of IP Address Reuse 65
User Reconnect After Logoff 65
Configuring SSG RADIUS Proxy for 802.1x Deployments 65
Monitoring and Maintaining SSG RADIUS Proxy 67
Troubleshooting SSG RADIUS Proxy 69
Examples 69
Configuration Examples for SSG Authentication of RADIUS Proxy Subscribers 71
SSG Autologon Using RADIUS Proxy: Examples 71
Enabling SSG AutoLogon Using RADIUS Proxy: Example 71
Configuring Session Identification Attributes: Examples 71
Configuring Timers for RADIUS Proxy: Examples 72
SSG RADIUS Proxy for CDMA2000: Examples 72
Configuring Multiple RADIUS Server Support: Example 73
Configuring Home Agent IP Addresses: Example 73
Removing VSA Types: Examples 73
SSG RADIUS Proxy for CDMA2000 - Complete Configuration: Example 73

vi
Contents
SSG RADIUS Proxy for 802.1x WLAN Deployments: Example 76
Where to Go Next 76
Feature Information for SSG RADIUS Proxy 77
Configuring SSG to Authenticate Web Logon Subscribers 81
Contents 81
Prerequisites for Configuring SSG to Authenticate Web Logon Subscribers 81
Restrictions for Configuring SSG to Authenticate Web Logon Subscribers 82
Information About Web Logon Subscribers 82

Web Logon 82
TCP Redirection of Unauthenticated Users 83
Restrictions for TCP Redirection of Unauthenticated Users 83
SSG 3-Key Authentication 84
How to Configure SSG to Authenticate Web Logon Subscribers 84
Configuring TCP Redirection for Unauthenticated Subscribers 84
Troubleshooting SSG TCP Redirection for Unauthenticated Subscribers 85
Configuration Examples for SSG Authentication for Web Logon Subscribers 87
Where to Go Next 88
Feature Information for Configuring SSG to Authenticate Web Logon Subscribers 89
Configuring SSG to Authenticate PPP Subscribers 91
Contents 91
Prerequisites 91
Restrictions 92
Information About SSG Authentication of PPP Subscribers 92

PPP Subscriber Access 92
PPP Termination Aggregation (PTA) 93
PTA-Multidomain 93
PTA-MD Exclusion Lists 93
Single Signon for PPP Subscribers 93
VPI/VCI Indexing to Service Profiles 94
How to Configure SSG to Authenticate PPP Subscribers 94
Configuring SSG Support for PPP Subscribers 94

vii
Contents
Configuring a PTA-MD Exclusion List 95

Configuring VPI/VCI Indexing to Services 96
Configuring Single Signon for PPP Subscribers 97
Configuration Examples for SSG Authentication of PPP Subscribers 98

Adding Domains to an Existing PTA-MD Exclusion List: Examples 98
Disabling Parsing of PPP Structured Usernames: Example 99
Service-Name-to-VC Mapping: Example 99
Configuring the Virtual Template to Support PPP Subscribers: Example 99
Basic PPPoA and PPPoE Configuration: Examples 99
PPPoA Users: Example 99
PPPoEoA Users: Example 100
PPPoEoE Users: Example 101
Where to Go Next 101

Feature Information for Configuring SSG to Authenticate PPP Subscribers 102
Configuring SSG to Authenticate Subscribers with Transparent Autologon 105
Contents 105
Prerequisites for SSG Transparent Autologon 105
Restrictions for SSG Transparent Autologon 106
Information About SSG Transparent Autologon 106

Overview of SSG Transparent Autologon 106
SSG Transparent Autologon User-to-Service Packet Flow 107
States of SSG Transparent Autologon Users 108
User with Host 108
Transparent Pass-Through User (TP) 108
User Waiting for Authorization (WA) 109
Suspect User (SP) 109
Unidentified User (NR) 109
Switching Between TP and Host User States 109
Benefits of SSG Transparent Autologon 110
How to Configure SSG Transparent Autologon 110
Configuring SSG Transparent Autologon 110
Configuring the AAA Subscriber Profile for SSG Transparent Autologon Subscribers 112
Monitoring and Maintaining SSG Transparent Autologon 112
Example 114
Troubleshooting SSG Transparent Autologon 115

viii
Contents
Example 115
Configuration Examples for SSG Transparent Autologon 117

SSG Transparent Autologon Configuration: Example 117
AAA User Profile Configuration for Transparent Passthrough (TP) Users: Example 117
AAA User Profile Configuration for Users with Hosts: Example 118

Feature Information for Configuring SSG to Authenticate Subscribers with Transparent Autologon 119
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain 121
Contents 121
Prerequisites for SSG AutoDomain 121
Restrictions for SSG AutoDomain 122
Information About SSG AutoDomain 122

Overview of SSG AutoDomain 122
IP Address Assignment 123
SSG AutoDomain Basic and Extended Modes 124
SSG AutoDomain Service Types 124
Access Point Names 124
AutoDomain Name Selection 125
Multiple Local IP Pools 125
Primary AutoDomain Service Termination 126
SSG AutoDomain and NAT 126
Benefits of SSG AutoDomain 127
How to Configure SSG AutoDomain 127
Configuring SSG AutoDomain 127
Monitoring and Maintaining SSG AutoDomain 129
Troubleshooting SSG AutoDomain 130
Configuration Examples for SSG AutoDomain 130
SSG AutoDomain: Example 131

Feature Information for Configuring SSG to Authenticate Subscribers Automatically in the Service
Domain 132

ix
Contents
Configuring SSG for On-Demand IP Address Renewal 135
Contents 135
Prerequisites for SSG On-Demand IP Address Renewal 135
Restrictions for SSG On-Demand IP Address Renewal 136
Information About SSG On-Demand IP Address Renewal 136

Overview of SSG On-Demand IP Address Renewal 136
DHCP Notification for SSG On-Demand IP Address Renewal 136
SSG On-Demand IP Address Renewal Packet Flow 137
Benefits of SSG On-Demand IP Address Renewal 138
How to Configure SSG for On-Demand IP Address Renewal 138
Configuring SSG On-Demand IP Address Renewal 138
Verifying and Troubleshooting SSG On-Demand IP Address Renewal 139
Verifying a Subscriber’s IP Address 139
Displaying Subscriber Login Events and Errors for the SSG On-Demand IP Address Renewal
Feature 140
Configuration Examples for SSG On-Demand IP Address Renewal 140
Configuring SSG for On-Demand IP Address Renewal: Example 141
Glossary 142
Feature Information for SSG On-Demand IP Address Renewal 142
Configuring SSG Support for Subnet-Based Authentication 145
Contents 145
Prerequisites for SSG Support for Subnet-Based Authentication 145
Restrictions for SSG Support for Subnet-Based Authentication 145
Information About SSG Support for Subnet-Based Authentication 146

Identifying Subnet-Based Subscribers 146
Benefits of SSG Support for Subnet-Based Authentication 146
How to Configure SSG Support for Subnet-Based Authentication 146
Verifying SSG Support for Subnet-Based Authentication 146
Feature Information for SSG Support for Subnet-Based Authentication 148
Configuring SSG for MAC-Address-Based Authentication 151
Contents 151

x
Contents
Prerequisites for MAC-Address-Based Authentication for SSG 151
Restrictions for MAC-Address-Based Authentication for SSG 152
Information About MAC-Address-Based Authentication for SSG 152

Overview of MAC-Address-Based Authentication for SSG 152
MAC Address as Username for Transparent Autologon 152
Subscriber Login with MAC-Address-Based Authentication for SSG 152
Explicit Login Call Flow 153
Implicit Login Call Flow 155
Benefits of MAC-Address-Based Authentication for SSG 156
How to Configure MAC-Address-Based Authentication for SSG 156
Configuring a DHCP Lease Query Request for MAC-Address-Based Authentication 156
Configuring an IP DHCP Lease Query Request 157
Configuration Examples for SSG MAC-Address-Based Authentication 158
Configuring SSG for MAC-Address-Based Authentication: Example 158
Configuring an IP DHCP Lease Query Request: Example 158
Feature Information for Configuring SSG for MAC-Address-Based Authentication 159
Configuring SSG for Subscriber Services 161
Contents 161
Prerequisites for Configuring SSG for Subscriber Services 161
Information About SSG Support for Subscriber Services 162

Services and Service Profiles 162
Authenticated Services 162
Pass-Through Services 163
Proxy Services 163
L2TP Dial-In Services 163
L2TP Dial-Out Services 164
DNS Packet Handling 164
How SSG Routes to Services 164
Open Garden (Unauthenticated) Services 165
Overview of SSG Open Garden Services 165
Open Garden Service Binding 165
Access Control Lists in Open Garden Services 166
Hierarchical Policing in Open Garden Services 166
SSG Uplink Interface Redundancy and Load Balancing 166
Overview of SSG Interface Redundancy 166

xi
Contents
SSG Uplink Interface Redundancy Topologies 167

DNS Packet Handling 169
SSG Transparent Pass-Through 169
Service Profile Caching 170
How to Configure Services for Subscribers 170
Configuring a Local Service Profile Using the Cisco IOS CLI 170
Configuring SSG Support for Services 171
What to Do Next 172
Configuring SSG to Support L2TP Dial-In Tunnel Services 173
Configuring SSG to Serve as a LAC 173
Configuring a VPDN Group 173
Configuring RADIUS Profiles for SSG Support of L2TP 174
Configuring the LNS 175
Monitoring and Maintaining SSG Support for L2TP Services 177
Configuring SSG to Support L2TP Dial-Out Services 177
Prerequisites for SSG L2TP Dial-Out 178
Restrictions for SSG L2TP Dial-Out 178
Overview of SSG L2TP Dial-Out 178
SSG L2TP Dial-Out Service Logon Through SESM 179
SSG L2TP Dial-Out Service Account Logon with Structured Username and Without SSG
Auto-Domain 180
SSG L2TP Dial-Out Service Logon with Structured Username and with SSG Auto-Domain 180
Configuring a Global Dial-Out Service Profile 181
Configuring the User Service Profile for L2TP Dial-Out Services 182
Configuring a DNIS Filter 182
Monitoring SSG L2TP Dial-Out 183
Troubleshooting SSG L2TP Dial-Out User Logon Failures 184
Troubleshooting SSG L2TP Dial-Out Service Login Failures 185
Configuring SSG Open Garden Services 186
Configuring SSG Transparent Pass-Through 187
Verifying SSG Transparent Pass-Through: Example 188
Monitoring and Maintaining SSG Support for Services 188
Troubleshooting SSG Support for Services 190
Configuration Examples for SSG Support for Subscriber Services 191
Service Profile Configuration: Examples 191
SSG Support for L2TP Tunnel Services: Examples 192
SSG Support for L2TP Dial-Out Services: Examples 193
Configuring SSG L2TP Dial-Out for SSG Without SSG Auto-Domain Enabled: Example 193
Configuring SSG L2TP Dial-Out for SSG with SSG Auto-Domain Enabled: Example 195
Configuring SSG L2TP Dial-Out User-Specific Configurations on the SOHO: Example 196

xii
Contents
Configuring a Large-Scale SSG L2TP Dial-Out Solution: Example 197

Configuring a Global Dial-Out Service Profile: Example 199
Configuring the Service Profiles for SSG L2TP Dial-Out: Example 200
Configuring the Service Profile to Send MSISDN Data: Example 200
Configuring a DNIS Filter: Example 200
SSG Interface Redundancy: Examples 201
SSG Open Garden Services: Example 202
SSG Transparent Pass-Through: Example 202
Feature Information for SSG Subscriber Services 203
Configuring SSG Subscriber Experience Features 207
Contents 207
Prerequisites for Configuring SSG Subscriber Experience Features 208
Information About SSG Subscriber Experience Features 208

SSG Hierarchical Policing Overview 209
SSG Per-User and Per-Session Policing 209
SSG Hierarchical Policing Token Bucket Scheme 210
SSG TCP Redirect Features Overview 213
SSG TCP Redirect for Services Overview 213
SSG TCP Redirect for Unauthenticated Users 213
SSG TCP Redirect for Unauthorized Services 214
SSG TCP Redirect Initial Captivation 215
SSG TCP Redirect Access Control Lists Overview 216
SSG Permanent TCP Redirection Overview 217
Per-Session Firewall Overview 220
Access List Attributes for User and Service Profiles 220
Downstream Access Control List Attribute—outacl 220
Upstream Access Control List Attribute—inacl 221
Restrictions for Per-Session Firewall 221
Default DNS Redirection Overview 222
DNS Redirection for Unauthenticated Users 222
SSG Domain Name Vendor-Specific Attribute 223
Restrictions for Dynamic DNS Assignment 223
How to Configure SSG Subscriber Experience Features 224
Configuring SSG Hierarchical Policing 224
Configuring a RADIUS User Profile for Per-User Policing 224

xiii
Contents
Configuring SSG Hierarchical Policing in a RADIUS Service Profile 225

Enabling SSG Hierarchical Policing on the Router 226
Troubleshooting SSG Hierarchical Policing 227
Configuring SSG TCP Redirection Features 229
Enabling SSG TCP Redirect for Services (Required) 229
Defining a Captive Portal Group 231
Configuring Initial and Periodic Captivation 232
Associating an Access Control List with a Redirection Group 234
Verifying SSG TCP Redirect Access Control Lists 236
Configuring TCP Redirection of Unauthenticated Subscribers 237
Configuring TCP Ports for Redirection 238
Configuring Unauthorized Service Redirection 239
Configuring SMTP Redirection 241
Configuring the RADIUS Attributes for SSG TCP Redirection 242
Configuring Permanent TCP Redirection for HTTP Proxy Support 242
Verifying SSG TCP Redirect for Services 244
Troubleshooting SSG TCP Redirection 246
Configuring a Per-Session Firewall 248
Configuring Default DNS Redirection 248
Configuring DNS Redirection in a Local Service Profile using the Cisco IOS CLI 249
Configuring Dynamic DNS Assignment on the AAA Server 250
Configuring DNS Fault tolerance 250
Configuration Examples for Configuring SSG Subscriber Experience Features 250
Enabling SSG TCP Redirect for Services: Example 251
Defining a Captive Portal Group: Example 251
Excluding Specific Traffic from Redirection: Example 251
Redirecting Traffic from Unauthenticated Users: Example 251
Configuring TCP Redirection of Unauthenticated Subscribers: Example 252
TCP Ports for a Portal Group Configuration: Example 252
Default Portal Group for Captivation: Example 252
Destination Networks Configuration: Example 253
Portal Group for SMTP Redirect Configuration: Example 253
RADIUS Attributes for SSG TCP Redirect Configuration: Example 253
SSG Default DNS Redirection Configuration: Example 254
SSG Default DNS Redirection for Unauthenticated Users Configuration: Example 254
Additional References Related to SSG Subscriber Experience Features 255

Standards 255
MIBs 255
RFCs 255

xiv
Contents
Feature Information for Configuring SSG Subscriber Experience Features 256
Configuring SSG to Log Off Subscribers 259
Contents 259
Prerequisites for Configuring SSG to Log Off Subscribers 259
Information About Configuring SSG to Log Off Subscribers 260

Graceful Logoff 260
Disconnection Through the Web Services Gateways 260
SSG Autologoff 260
SSG Autologoff Using ARP Ping 260
MAC Address Checking for Autologoff 261
SSG Autologoff Using ICMP Ping 261
Benefits of SSG Autologoff 261
SSG Session Timeout and Idle Timeout 261
How to Configure SSG to Log Off Subscribers 262
Configuring SSG Autologoff 262
Restrictions 262
Configuring Global SSG Session Timeouts and Idle Timeouts 263
Troubleshooting SSG Subscriber Logoff 264
Configuration Examples for Configuring SSG to Log Off Subscribers 265
SSG Autologoff Using ARP Ping: Example 265
SSG Autologoff Using ICMP Ping: Example 265
SSG MAC Address Checking for Autologoff: Example 265
RFCs 266
Feature Information for Configuring SSG to Log Off Subscribers 266
Configuring SSG Accounting 269
Contents 269
Prerequisites for SSG Accounting 269
Information About SSG Accounting 269

RADIUS Accounting Records Used by SSG 270
Account Logon and Logoff 270
Service Logon and Logoff 271
Types of SSG Accounting 272
Interim Accounting 272

xv
Contents
Per-Host Accounting 272

Per-Service Accounting 273
SSG Accounting Update Interval per Service Feature 273
Broadcast Accounting 273
SSG Prepaid Functionality 273
Service Authorization 274
Service Reauthorization 276
Accounting Records and Prepaid Billing 276
Simultaneous Volume- and Time-Based Prepaid Billing 277
SSG Prepaid Idle Timeout 277
SSG Prepaid Reauthorization Threshold 279
SSG Prepaid Redirection on Quota Exhaustion Feature 279
Default Quota for Prepaid Server Failure 280
Benefits of the SSG Prepaid Feature 280
Prepaid Tariff Switching 281
Authorization and Reauthorization Behavior When Prepaid Tariff Switching Occurs 281
SSG Prepaid Tariff Switching VSAs 282
Interim Accounting Updates for SSG Prepaid Tariff Switching 283
Dual Quota and Idle-Timeout Prepaid Tariff Switching 284
Extended Prepaid Tariff Switching for SSG 285
Postpaid Tariff Switching for SSG 285
How to Configure SSG Accounting 286
Configuring SSG Accounting 286
Prerequisites for Configuring SSG Accounting 286
Configuring SSG Broadcast Accounting 287
Configuring SSG Prepaid Features 288
Configuring SSG Prepaid Features on the Router 288
Configuring RADIUS Service Profiles for the SSG Prepaid Support Feature 290
Redirecting TCP Traffic for SSG Prepaid Quota Refill 290
Verifying Configuration of the SSG Prepaid Feature 292
Configuring Postpaid Tariff Switching for SSG 295
Post-Paid VSA 295
Examples 296
Configuration Examples for SSG Accounting 296
Accounting Update Interval per Service in RADIUS: Example 296
Basic Prepaid Configuration: Examples 297
TCP Redirect for Prepaid Users: Example 297
Configuring Prepaid Threshold Value: Examples 297

xvi
Contents

Feature Information for SSG Accounting 298
RADIUS Profiles and Attributes for SSG 301
Contents 301
Prerequisites for RADIUS Profiles and Attributes for SSG 301
Information About RADIUS Profiles and Attributes for SSG 301

RADIUS Profiles for SSG Support 301
SSG Vendor-Specific Attributes 302
Subscriber Profiles 329
Service Profiles 332
Service Group Profiles 341
Pseudo-Service Profiles 342
Examples of SSG RADIUS Profiles 345
RADIUS Accounting Records for SSG 348
Account Logon 348
Account Logoff 348
Connection Start 349
Connection Stop 350
Attributes Used in Accounting Records 352
Feature Information for RADIUS Profiles and Attributes for SSG 357

xvii
Contents

xviii
About Cisco IOS Software Documentation for
Release 12.4
This chapter describes the objectives, audience, organization, and conventions of Cisco IOS software
documentation. It also provides sources for obtaining documentation, technical assistance, and
additional publications and information from Cisco Systems. It contains the following sections:
• Documentation Objectives, page xix
• Audience, page xix
• Documentation Organization for Cisco IOS Release 12.4, page xx
• Document Conventions, page xxvi
• Obtaining Documentation, page xxvii
• Documentation Feedback, page xxviii
• Cisco Product Security Overview, page xxix
• Obtaining Technical Assistance, page xxx
• Obtaining Additional Publications and Information, page xxxi
Documentation Objectives
Cisco IOS software documentation describes the tasks and commands available to configure and
maintain Cisco networking devices.
Audience
The Cisco IOS software documentation set is intended primarily for users who configure and maintain
Cisco networking devices (such as routers and switches) but who may not be familiar with the
configuration and maintenance tasks, the relationship among tasks, or the Cisco IOS software commands
necessary to perform particular tasks. The Cisco IOS software documentation set is also intended for
those users experienced with Cisco IOS software who need to know about new features, new
configuration options, and new software characteristics in the current Cisco IOS software release.

xix
About Cisco IOS Software Documentation for Release 12.4
Documentation Organization for Cisco IOS Release 12.4

The Cisco IOS Release 12.4 documentation set consists of the configuration guide and command
reference pairs listed in Table 1 and the supporting documents listed in Table 2. The configuration guides
and command references are organized by technology. For the configuration guides:
• Some technology documentation, such as that for DHCP, contains features introduced in
Releases 12.2T and 12.3T and, in some cases, Release 12.2S. To assist you in finding a particular
feature, a roadmap document is provided.
• Other technology documentation, such as that for OSPF, consists of a chapter and accompanying
Release 12.2T and 12.3T feature documents.
Note In some cases, information contained in Release 12.2T and 12.3T feature documents augments or
supersedes content in the accompanying documentation. Therefore it is important to review all
feature documents for a particular technology.
Table 1 lists the Cisco IOS Release 12.4 configuration guides and command references.
Table 1 Cisco IOS Release 12.4 Configuration Guides and Command References
Configuration Guide and Description

Command Reference Titles
IP
Cisco IOS IP Addressing Services The configuration guide is a task-oriented guide to configuring IP addressing and
Configuration Guide, Release 12.4 services, including Network Address Translation (NAT), Domain Name System
(DNS), and Dynamic Host Configuration Protocol (DHCP). The command
Cisco IOS IP Addressing Services
reference provides detailed information about the commands used in the
Command Reference, Release 12.4
configuration guide.
Cisco IOS IP Application Services The configuration guide is a task-oriented guide to configuring IP application
Configuration Guide, Release 12.4 services, including IP access lists, Web Cache Communication Protocol
(WCCP), Gateway Load Balancing Protocol (GLBP), Server Load Balancing
Cisco IOS IP Application Services
(SLB), Hot Standby Router Protocol (HSRP), and Virtual Router Redundancy
Protocol (VRRP). The command reference provides detailed information about
the commands used in the configuration guide.
Cisco IOS IP Mobility The configuration guide is a task-oriented guide to configuring Mobile IP and
Configuration Guide, Release 12.4 Cisco Mobile Networks. The command reference provides detailed information
about the commands used in the configuration guide.
Cisco IOS IP Mobility
Cisco IOS IP Multicast The configuration guide is a task-oriented guide to configuring IP multicast,
Configuration Guide, Release 12.4 including Protocol Independent Multicast (PIM), Internet Group Management
Protocol (IGMP), Distance Vector Multicast Routing Protocol (DVMRP), and
Cisco IOS IP Multicast
Multicast Source Discovery Protocol (MSDP). The command reference provides
detailed information about the commands used in the configuration guide.
Cisco IOS IP Routing Protocols The configuration guide is a task-oriented guide to configuring IP routing
Configuration Guide, Release 12.4 protocols, including Border Gateway Protocol (BGP), Intermediate
System-to-Intermediate System (IS-IS), and Open Shortest Path First (OSPF).
Cisco IOS IP Routing Protocols
The command reference provides detailed information about the commands used
in the configuration guide.

xx
Table 1 Cisco IOS Release 12.4 Configuration Guides and Command References (continued)

Cisco IOS IP Switching The configuration guide is a task-oriented guide to configuring IP switching
Configuration Guide, Release 12.4 features, including Cisco Express Forwarding, fast switching, and Multicast
Distributed Switching (MDS). The command reference provides detailed
Cisco IOS IP Switching
information about the commands used in the configuration guide.
Cisco IOS IPv6 The configuration guide is a task-oriented guide to configuring IP version 6
Configuration Guide, Release 12.4 (IPv6), including IPv6 broadband access, IPv6 data-link layer, IPv6 multicast
routing, IPv6 quality of service (QoS), IPv6 routing, IPv6 services and
Cisco IOS IPv6
management, and IPv6 tunnel services. The command reference provides
Cisco IOS Optimized Edge Routing The configuration guide is a task-oriented guide to configuring Optimized Edge
Configuration Guide, Release 12.4 Routing (OER) features, including OER prefix learning, OER prefix monitoring,
OER operational modes, and OER policy configuration. The command reference
Cisco IOS Optimized Edge Routing
provides detailed information about the commands used in the configuration
guide.
Security and VPN
Cisco IOS Security The configuration guide is a task-oriented guide to configuring various aspects of
Configuration Guide, Release 12.4 security, including terminal access security, network access security, accounting,
traffic filters, router access, and network data encryption with router
Cisco IOS Security
authentication. The command reference provides detailed information about the
commands used in the configuration guide.
QoS
Cisco IOS Quality of Service Solutions The configuration guide is a task-oriented guide to configuring quality of service
Configuration Guide, Release 12.4 (QoS) features, including traffic classification and marking, traffic policing and
shaping, congestion management, congestion avoidance, and signaling. The
Cisco IOS Quality of Service Solutions
command reference provides detailed information about the commands used in
the configuration guide.
LAN Switching
Cisco IOS LAN Switching The configuration guide is a task-oriented guide to local-area network (LAN)
Configuration Guide, Release 12.4 switching features, including configuring routing between virtual LANs
(VLANs) using Inter-Switch Link (ISL) encapsulation, IEEE 802.10
Cisco IOS LAN Switching
encapsulation, and IEEE 802.1Q encapsulation. The command reference
guide.
Multiprotocol Label Switching (MPLS)
Cisco IOS Multiprotocol Label Switching The configuration guide is a task-oriented guide to configuring Multiprotocol
Configuration Guide, Release 12.4 Label Switching (MPLS), including MPLS Label Distribution Protocol, MPLS
traffic engineering, and MPLS Virtual Private Networks (VPNs). The command
Cisco IOS Multiprotocol Label Switching
Network Management
Cisco IOS IP SLAs The configuration guide is a task-oriented guide to configuring the Cisco IOS IP
Configuration Guide, Release 12.4 Service Level Assurances (IP SLAs) feature. The command reference provides
Cisco IOS IP SLAs

xxi

Cisco IOS NetFlow The configuration guide is a task-oriented guide to NetFlow features, including
Configuration Guide, Release 12.4 configuring NetFlow to analyze network traffic data, configuring NetFlow
aggregation caches and export features, and configuring Simple Network
Cisco IOS NetFlow
Management Protocol (SNMP) and NetFlow MIB features. The command
Cisco IOS Network Management The configuration guide is a task-oriented guide to network management
Configuration Guide, Release 12.4 features, including performing basic system management, performing
troubleshooting and fault management, configuring Cisco Discovery Protocol,
Cisco IOS Network Management
configuring Cisco Networking Services (CNS), configuring DistributedDirector,
and configuring Simple Network Management Protocol (SNMP). The command
Voice
Cisco IOS Voice The configuration library is a task-oriented collection of configuration guides,
Configuration Library, Release 12.4 application guides, a troubleshooting guide, feature documents, a library preface, a
voice glossary, and more. It also covers Cisco IOS support for voice call control
Cisco IOS Voice
protocols, interoperability, physical and virtual interface management, and
troubleshooting. In addition, the library includes documentation for IP telephony
applications. The command reference provides detailed information about the
commands used in the configuration library.
Wireless/Mobility
Cisco IOS Mobile Wireless The configuration guide is a task-oriented guide to understanding and configuring a
Gateway GPRS Support Node Cisco IOS Gateway GPRS Support Node (GGSN) in a 2.5G General Packet Radio
Configuration Guide, Release 12.4 Service (GPRS) and 3G Universal Mobile Telecommunication System (UMTS)
network. The command reference provides detailed information about the
Cisco IOS Mobile Wireless
Gateway GPRS Support Node
Cisco IOS Mobile Wireless The configuration guide is a task-oriented guide to understanding and configuring the
Home Agent Cisco Mobile Wireless Home Agent, which is an anchor point for mobile terminals
Configuration Guide, Release 12.4 for which Mobile IP or Proxy Mobile IP services are provided. The command
Home Agent
Cisco IOS Mobile Wireless The configuration guide is a task-oriented guide to understanding and configuring the
Packet Data Serving Node Cisco Packet Data Serving Node (PDSN), a wireless gateway between the mobile
Configuration Guide, Release 12.4 infrastructure and standard IP networks that enables packet data services in a Code
Division Multiple Access (CDMA) environment. The command reference provides
Packet Data Serving Node

xxii

Cisco IOS Mobile Wireless The configuration guide is a task-oriented guide to understanding and
Radio Access Networking configuring Cisco IOS Radio Access Network products. The command reference
Configuration Guide, Release 12.4 provides detailed information about the commands used in the configuration
guide.
Radio Access Networking
Long Reach Ethernet (LRE) and Digital Subscriber Line (xDSL)
Cisco IOS Broadband and DSL The configuration guide is a task-oriented guide to configuring broadband access
Configuration Guide, Release 12.4 aggregation and digital subscriber line features. The command reference
Cisco IOS Broadband and DSL
guide.
Cisco IOS Service Selection Gateway The configuration guide is a task-oriented guide to configuring Service Selection
Configuration Guide, Release 12.4 Gateway (SSG) features, including subscriber authentication, service access, and
accounting. The command reference provides detailed information about the
Cisco IOS Service Selection Gateway
Dial—Access
Cisco IOS Dial Technologies The configuration guide is a task-oriented guide to configuring lines, modems,
Configuration Guide, Release 12.4 and ISDN services. This guide also contains information about configuring
dialup solutions, including solutions for remote sites dialing in to a central office,
Cisco IOS Dial Technologies
Internet service providers (ISPs), ISP customers at home offices, enterprise WAN
system administrators implementing dial-on-demand routing, and other
corporate environments. The command reference provides detailed information
about the commands used in the configuration guide.
Cisco IOS VPDN The configuration guide is a task-oriented guide to configuring Virtual Private
Configuration Guide, Release 12.4 Dialup Networks (VPDNs), including information about Layer 2 tunneling
protocols, client-initiated VPDN tunneling, NAS-initiated VPDN tunneling, and
Cisco IOS VPDN
multihop VPDN. The command reference provides detailed information about
the commands used in the configuration guide.
Asynchronous Transfer Mode (ATM)
Cisco IOS Asynchronous Transfer Mode The configuration guide is a task-oriented guide to configuring Asynchronous
Configuration Guide, Release 12.4 Transfer Mode (ATM), including WAN ATM, LAN ATM, and multiprotocol over
ATM (MPOA). The command reference provides detailed information about the
Cisco IOS Asynchronous Transfer Mode
WAN
Cisco IOS Wide-Area Networking The configuration guide is a task-oriented guide to configuring wide-area
Configuration Guide, Release 12.4 network (WAN) features, including Layer 2 Tunneling Protocol Version 3
(L2TPv3); Frame Relay; Link Access Procedure, Balanced (LAPB); and X.25.
Cisco IOS Wide-Area Networking
The command reference provides detailed information about the commands used
in the configuration guide.

xxiii

System Management
Cisco IOS Configuration Fundamentals The configuration guide is a task-oriented guide to using Cisco IOS software to
Configuration Guide, Release 12.4 configure and maintain Cisco routers and access servers, including information
about using the Cisco IOS command-line interface (CLI), loading and
Cisco IOS Configuration Fundamentals
maintaining system images, using the Cisco IOS file system, using the Cisco IOS
Web browser user interface (UI), and configuring basic file transfer services. The
command reference provides detailed information about the commands used in
the configuration guide.
Cisco IOS The configuration guide is a task-oriented guide to configuring and managing
Interface and Hardware Component interfaces and hardware components, including dial shelves, LAN interfaces,
Configuration Guide, Release 12.4 logical interfaces, serial interfaces, and virtual interfaces. The command
Cisco IOS
Interface and Hardware Component
IBM Technologies
Cisco IOS Bridging and IBM Networking The configuration guide is a task-oriented guide to configuring:
Configuration Guide, Release 12.4
• Bridging features, including transparent and source-route transparent (SRT)
Cisco IOS Bridging bridging, source-route bridging (SRB), Token Ring Inter-Switch Link
Command Reference, Release 12.4 (TRISL), and Token Ring Route Switch Module (TRRSM).
Cisco IOS IBM Networking • IBM network features, including data-link switching plus (DLSw+), serial
Command Reference, Release 12.4 tunnel (STUN), and block serial tunnel (BSTUN); Logical Link Control,
type 2 (LLC2), and Synchronous Data Link Control (SDLC); IBM Network
Media Translation, including SDLC Logical Link Control (SDLLC) and
Qualified Logical Link Control (QLLC); downstream physical unit (DSPU),
Systems Network Architecture (SNA) service point, SNA Frame Relay
Access, Advanced Peer-to-Peer Networking (APPN), native client interface
architecture (NCIA) client/server topologies, and IBM Channel Attach.
The two command references provide detailed information about the commands
used in the configuration guide.
Additional and Legacy Protocols
Cisco IOS AppleTalk The configuration guide is a task-oriented guide to configuring the AppleTalk
Configuration Guide, Release 12.4 protocol. The command reference provides detailed information about the
Cisco IOS AppleTalk
Cisco IOS DECnet The configuration guide is a task-oriented guide to configuring the DECnet
Configuration Guide, Release 12.4 protocol. The command reference provides detailed information about the
Cisco IOS DECnet
Cisco IOS ISO CLNS The configuration guide is a task-oriented guide to configuring International
Configuration Guide, Release 12.4 Organization for Standardization (ISO) Connectionless Network Service
(CLNS). The command reference provides detailed information about the
Cisco IOS ISO CLNS

xxiv

Cisco IOS Novell IPX The configuration guide is a task-oriented guide to configuring the Novell
Configuration Guide, Release 12.4 Internetwork Packet Exchange (IPX) protocol. The command reference provides
Cisco IOS Novell IPX
Cisco IOS Terminal Services The configuration guide is a task-oriented guide to configuring terminal services,
Configuration Guide, Release 12.4 including DEC, local-area transport (LAT), and X.25 packet
assembler/disassembler (PAD). The command reference provides detailed
Cisco IOS Terminal Services
information about the commands used in the configuration guide.
Table 2 lists the documents and resources that support the Cisco IOS Release 12.4 software
configuration guides and command references.
Table 2 Cisco IOS Release 12.4 Supporting Documents and Resources
Document Title Description

Cisco IOS Master Commands List, An alphabetical listing of all the commands documented in the Cisco IOS
Release 12.4 Release 12.4 command references.
Cisco IOS New, Modified, Replaced, A listing of all the new, modified, replaced and removed commands since
and Removed Commands, Release 12.4 Cisco IOS Release 12.3, grouped by Release 12.3T maintenance release and
ordered alphabetically within each group.
Cisco IOS New and Modified A listing of all the new, modified, and replaced commands since Cisco IOS
Commands, Release 12.3 Release 12.2, grouped by Release 12.2T maintenance release and ordered
alphabetically within each group.
Cisco IOS System Messages, Listings and descriptions of Cisco IOS system messages. Not all system messages
Volume 1 of 2 indicate problems with your system. Some are purely informational, and others
may help diagnose problems with communications lines, internal hardware, or the
Cisco IOS System Messages,
system software.
Volume 2 of 2
Cisco IOS Debug Command Reference, An alphabetical listing of the debug commands and their descriptions.
Release 12.4 Documentation for each command includes a brief description of its use, command
syntax, and usage guidelines.
Release Notes, Release 12.4 A description of general release information, including information about
supported platforms, feature sets, platform-specific notes, and Cisco IOS software
defects.
Internetworking Terms and Acronyms Compilation and definitions of the terms and acronyms used in the internetworking
industry.

xxv
Document Conventions
Table 2 Cisco IOS Release 12.4 Supporting Documents and Resources (continued)
Document Title Description

RFCs RFCs are standards documents maintained by the Internet Engineering Task Force
(IETF). Cisco IOS software documentation references supported RFCs when
applicable. The full text of referenced RFCs may be obtained at the following URL:
http://www.rfc-editor.org/
MIBs MIBs are used for network monitoring. To locate and download MIBs for selected
platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the
following URL:
http://www.cisco.com/go/mibs
Document Conventions
Within Cisco IOS software documentation, the term router is generally used to refer to a variety of Cisco
products (for example, routers, access servers, and switches). Routers, access servers, and other
networking devices that support Cisco IOS software are shown interchangeably within examples. These
products are used only for illustrative purposes; that is, an example that shows one product does not
necessarily indicate that other products are not supported.
The Cisco IOS documentation set uses the following conventions:
Convention Description
^ or Ctrl The ^ and Ctrl symbols represent the Control key. For example, the key combination ^D or Ctrl-D
means hold down the Control key while you press the D key. Keys are indicated in capital letters but
are not case sensitive.
string A string is a nonquoted set of characters shown in italics. For example, when setting an SNMP
community string to public, do not use quotation marks around the string or the string will include the
quotation marks.
Command syntax descriptions use the following conventions:
bold Bold text indicates commands and keywords that you enter literally as shown.
italics Italic text indicates arguments for which you supply values.
[x] Square brackets enclose an optional element (keyword or argument).
| A vertical line indicates a choice within an optional or required set of keywords or arguments.
[x | y] Square brackets enclosing keywords or arguments separated by a vertical line indicate an optional
choice.
{x | y} Braces enclosing keywords or arguments separated by a vertical line indicate a required choice.

xxvi
Obtaining Documentation
Nested sets of square brackets or braces indicate optional or required choices within optional or required
elements. For example:
[x {y | z}] Braces and a vertical line within square brackets indicate a required choice within an optional element.
Examples use the following conventions:
screen Examples of information displayed on the screen are set in Courier font.
bold screen Examples of text that you must enter are set in Courier bold font.
< > Angle brackets enclose text that is not printed to the screen, such as passwords, and are used in
contexts in which the italic document convention is not available, such as ASCII text.
! An exclamation point at the beginning of a line indicates a comment line. (Exclamation points are also
displayed by the Cisco IOS software for certain processes.)
[ ] Square brackets enclose default responses to system prompts.
The following conventions are used to attract the attention of the reader:
Caution Means reader be careful. In this situation, you might do something that could result in equipment
damage or loss of data.
Note Means reader take note. Notes contain suggestions or references to material not covered in the
manual.
Timesaver Means the described action saves time. You can save time by performing the action described in the
paragraph.
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several
ways to obtain technical assistance and other technical resources. These sections explain how to obtain
technical information from Cisco Systems.
Cisco.com
You can access the most current Cisco documentation and technical support at this URL:
http://www.cisco.com/techsupport

xxvii
Documentation Feedback
You can access the Cisco website at this URL:

http://www.cisco.com
You can access international Cisco websites at this URL:
http://www.cisco.com/public/countries_languages.shtml
Product Documentation DVD

Cisco documentation and additional literature are available in the Product Documentation DVD package,
which may have shipped with your product. The Product Documentation DVD is updated regularly and
may be more current than printed documentation.
The Product Documentation DVD is a comprehensive library of technical product documentation on
portable media. The DVD enables you to access multiple versions of hardware and software installation,
configuration, and command guides for Cisco products and to view technical documentation in HTML.
With the DVD, you have access to the same documentation that is found on the Cisco website without
being connected to the Internet. Certain products also have .pdf versions of the documentation available.
The Product Documentation DVD is available as a single unit or as a subscription. Registered Cisco.com
users (Cisco direct customers) can order a Product Documentation DVD (product number
DOC-DOCDVD=) from Cisco Marketplace at this URL:
http://www.cisco.com/go/marketplace/
Ordering Documentation
Beginning June 30, 2005, registered Cisco.com users may order Cisco documentation at the Product
Documentation Store in the Cisco Marketplace at this URL:
Nonregistered Cisco.com users can order technical documentation from 8:00 a.m. to 5:00 p.m.
(0800 to 1700) PDT by calling 1 866 463-3487 in the United States and Canada, or elsewhere by
calling 011 408 519-5055. You can also order documentation by e-mail at
tech-doc-store-mkpl@external.cisco.com or by fax at 1 408 519-5001 in the United States and Canada,
or elsewhere at 011 408 519-5001.
Documentation Feedback
You can rate and provide feedback about Cisco technical documents by completing the online feedback
form that appears with the technical documents on Cisco.com.
You can send comments about Cisco documentation to bug-doc@cisco.com.
You can submit comments by using the response card (if present) behind the front cover of your
document or by writing to the following address:
Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.

xxviii
Cisco Product Security Overview
Cisco Product Security Overview

Cisco provides a free online Security Vulnerability Policy portal at this URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
From this site, you can perform these tasks:
• Report security vulnerabilities in Cisco products.
• Obtain assistance with security incidents that involve Cisco products.
• Register to receive security information from Cisco.
A current list of security advisories and notices for Cisco products is available at this URL:
http://www.cisco.com/go/psirt
If you prefer to see advisories and notices as they are updated in real time, you can access a Product
Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed from this URL:
http://www.cisco.com/en/US/products/products_psirt_rss_feed.html
Reporting Security Problems in Cisco Products

Cisco is committed to delivering secure products. We test our products internally before we release them,
and we strive to correct all vulnerabilities quickly. If you think that you might have identified a
vulnerability in a Cisco product, contact PSIRT:
• Emergencies — security-alert@cisco.com
An emergency is either a condition in which a system is under active attack or a condition for which
a severe and urgent security vulnerability should be reported. All other conditions are considered
nonemergencies.
• Nonemergencies — psirt@cisco.com
In an emergency, you can also reach PSIRT by telephone:
• 1 877 228-7302
• 1 408 525-6532
Tip We encourage you to use Pretty Good Privacy (PGP) or a compatible product to encrypt any sensitive
information that you send to Cisco. PSIRT can work from encrypted information that is compatible with
PGP versions 2.x through 8.x.
Never use a revoked or an expired encryption key. The correct public key to use in your correspondence
with PSIRT is the one linked in the Contact Summary section of the Security Vulnerability Policy page
at this URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
The link on this page has the current PGP key ID in use.

xxix
Obtaining Technical Assistance
Obtaining Technical Assistance

Cisco Technical Support provides 24-hour-a-day award-winning technical assistance. The
Cisco Technical Support & Documentation website on Cisco.com features extensive online support
resources. In addition, if you have a valid Cisco service contract, Cisco Technical Assistance Center
(TAC) engineers provide telephone support. If you do not have a valid Cisco service contract, contact
your reseller.
Cisco Technical Support & Documentation Website

The Cisco Technical Support & Documentation website provides online documents and tools for
troubleshooting and resolving technical issues with Cisco products and technologies. The website is
available 24 hours a day, at this URL:
http://www.cisco.com/techsupport
Access to all tools on the Cisco Technical Support & Documentation website requires a Cisco.com user
ID and password. If you have a valid service contract but do not have a user ID or password, you can
register at this URL:
http://tools.cisco.com/RPF/register/register.do
Note Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting
a web or phone request for service. You can access the CPI tool from the Cisco Technical Support &
Documentation website by clicking the Tools & Resources link. Choose Cisco Product Identification
Tool from the Alphabetical Index drop-down list, or click the Cisco Product Identification Tool link
under Alerts & RMAs. The CPI tool offers three search options: by product ID or model name; by tree
view; or for certain products, by copying and pasting show command output. Search results show an
illustration of your product with the serial number label location highlighted. Locate the serial number
label on your product and record the information before placing a service call.
Submitting a Service Request

Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3
and S4 service requests are those in which your network is minimally impaired or for which you require
product information.) After you describe your situation, the TAC Service Request Tool provides
recommended solutions. If your issue is not resolved using the recommended resources, your service
request is assigned to a Cisco engineer. The TAC Service Request Tool is located at this URL:
http://www.cisco.com/techsupport/servicerequest
For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone.
(S1 or S2 service requests are those in which your production network is down or severely degraded.)
Cisco engineers are assigned immediately to S1 and S2 service requests to help keep your business
operations running smoothly.
To open a service request by telephone, use one of the following numbers:
Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447

xxx
Obtaining Additional Publications and Information
For a complete list of Cisco TAC contacts, go to this URL:

http://www.cisco.com/techsupport/contacts
Definitions of Service Request Severity

To ensure that all service requests are reported in a standard format, Cisco has established severity
definitions.
Severity 1 (S1)—Your network is “down,” or there is a critical impact to your business operations. You
and Cisco will commit all necessary resources around the clock to resolve the situation.
Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your
business operation are negatively affected by inadequate performance of Cisco products. You and Cisco
will commit full-time resources during normal business hours to resolve the situation.
Severity 3 (S3)—Operational performance of your network is impaired, but most business operations
remain functional. You and Cisco will commit resources during normal business hours to restore service
to satisfactory levels.
Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or
configuration. There is little or no effect on your business operations.

Information about Cisco products, technologies, and network solutions is available from various online
and printed sources.
• Cisco Marketplace provides a variety of Cisco books, reference guides, documentation, and logo
merchandise. Visit Cisco Marketplace, the company store, at this URL:
• Cisco Press publishes a wide range of general networking, training and certification titles. Both new
and experienced users will benefit from these publications. For current Cisco Press titles and other
information, go to Cisco Press at this URL:
http://www.ciscopress.com
• Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and
networking investments. Each quarter, Packet delivers coverage of the latest industry trends,
technology breakthroughs, and Cisco products and solutions, as well as network deployment and
troubleshooting tips, configuration examples, customer case studies, certification and training
information, and links to scores of in-depth online resources. You can access Packet magazine at
this URL:
http://www.cisco.com/packet
• iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies
learn how they can use technology to increase revenue, streamline their business, and expand
services. The publication identifies the challenges facing these companies and the technologies to
help solve them, using real-world case studies and business strategies to help readers make sound
technology investment decisions. You can access iQ Magazine at this URL:
http://www.cisco.com/go/iqmagazine
or view the digital edition at this URL:
http://ciscoiq.texterity.com/ciscoiq/sample/

xxxi
• Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering
professionals involved in designing, developing, and operating public and private internets and
intranets. You can access the Internet Protocol Journal at this URL:
http://www.cisco.com/ipj
• Networking products offered by Cisco Systems, as well as customer support services, can be
obtained at this URL:
http://www.cisco.com/en/US/products/index.html
• Networking Professionals Connection is an interactive website for networking professionals to share
questions, suggestions, and information about networking products and technologies with Cisco
experts and other networking professionals. Join a discussion at this URL:
http://www.cisco.com/discuss/networking
• World-class networking training is available from Cisco. You can view current offerings at
this URL:
http://www.cisco.com/en/US/learning/index.html

xxxii
Using Cisco IOS Software for Release 12.4
This chapter provides tips for understanding and configuring Cisco IOS software using the
command-line interface (CLI). It contains the following sections:
• Understanding Command Modes, page xxxiii
• Getting Help, page xxxiv
• Using the no and default Forms of Commands, page xxxviii
• Saving Configuration Changes, page xxxviii
• Filtering Output from the show and more Commands, page xxxix
• Finding Additional Feature Support Information, page xxxix
For an overview of Cisco IOS software configuration, see the Cisco IOS Configuration Fundamentals
Configuration Guide.
For information on the conventions used in the Cisco IOS software documentation set, see the “About
Cisco IOS Software Documentation for Release 12.4” chapter.
Understanding Command Modes

You use the CLI to access Cisco IOS software. Because the CLI is divided into many different modes,
the commands available to you at any given time depend on the mode that you are currently in. Entering
a question mark (?) at the CLI prompt allows you to obtain a list of commands available for each
command mode.
When you log in to a Cisco device, the device is initially in user EXEC mode. User EXEC mode contains
only a limited subset of commands. To have access to all commands, you must enter privileged EXEC
mode by entering the enable command and a password (when required). From privileged EXEC mode
you have access to both user EXEC and privileged EXEC commands. Most EXEC commands are used
independently to observe status or to perform a specific function. For example, show commands are used
to display important status information, and clear commands allow you to reset counters or interfaces.
The EXEC commands are not saved when the software reboots.
Configuration modes allow you to make changes to the running configuration. If you later save the
running configuration to the startup configuration, these changed commands are stored when the
software is rebooted. To enter specific configuration modes, you must start at global configuration mode.
From global configuration mode, you can enter interface configuration mode and a variety of other
modes, such as protocol-specific modes.

xxxiii
Getting Help
ROM monitor mode is a separate mode used when the Cisco IOS software cannot load properly. If a valid
software image is not found when the software boots or if the configuration file is corrupted at startup,
the software might enter ROM monitor mode.
Table 1 describes how to access and exit various common command modes of the Cisco IOS software.
It also shows examples of the prompts displayed for each mode.
Table 1 Accessing and Exiting Command Modes
Command Access Method Prompt Exit Method

Mode
User EXEC Log in. Router> Use the logout command.
Privileged From user EXEC mode, Router# To return to user EXEC mode, use the disable
EXEC use the enable command. command.
Global From privileged EXEC Router(config)# To return to privileged EXEC mode from global
configuration mode, use the configure configuration mode, use the exit or end command.
terminal command.
Interface From global Router(config-if)# To return to global configuration mode, use the exit
configuration configuration mode, command.
specify an interface using To return to privileged EXEC mode, use the end
an interface command. command.
ROM monitor From privileged EXEC > To exit ROM monitor mode, use the continue
mode, use the reload command.
command. Press the
Break key during the
first 60 seconds while the
system is booting.
For more information on command modes, see the “Using the Cisco IOS Command-Line Interface”
chapter in the Cisco IOS Configuration Fundamentals Configuration Guide.
Getting Help
Entering a question mark (?) at the CLI prompt displays a list of commands available for each command
mode. You can also get a list of keywords and arguments associated with any command by using the
context-sensitive help feature.
To get help specific to a command mode, a command, a keyword, or an argument, use one of the
following commands:
Command Purpose
help Provides a brief description of the help system in any command mode.
abbreviated-command-entry? Provides a list of commands that begin with a particular character string. (No space
between command and question mark.)
abbreviated-command-entry<Tab> Completes a partial command name.

xxxiv
Getting Help
Command Purpose
? Lists all commands available for a particular command mode.
command ? Lists the keywords or arguments that you must enter next on the command line.
(Space between command and question mark.)
Example: How to Find Command Options

This section provides an example of how to display syntax for a command. The syntax can consist of
optional or required keywords and arguments. To display keywords and arguments for a command, enter
a question mark (?) at the configuration prompt or after entering part of a command followed by a space.
The Cisco IOS software displays a list and brief description of available keywords and arguments. For
example, if you were in global configuration mode and wanted to see all the keywords or arguments for
the arap command, you would type arap ?.
The <cr> symbol in command help output stands for “carriage return.” On older keyboards, the carriage
return key is the Return key. On most modern keyboards, the carriage return key is the Enter key. The
<cr> symbol at the end of command help output indicates that you have the option to press Enter to
complete the command and that the arguments and keywords in the list preceding the <cr> symbol are
optional. The <cr> symbol by itself indicates that no more arguments or keywords are available and that
you must press Enter to complete the command.
Table 2 shows examples of how you can use the question mark (?) to assist you in entering commands.
The table steps you through configuring an IP address on a serial interface on a Cisco 7206 router that
is running Cisco IOS Release 12.0(3).
Table 2 How to Find Command Options
Command Comment
Router> enable Enter the enable command and
Password: <password> password to access privileged EXEC
Router#
commands. You are in privileged
EXEC mode when the prompt changes
to Router#.
Router# configure terminal Enter the configure terminal
Enter configuration commands, one per line. End with CNTL/Z. privileged EXEC command to enter
Router(config)#
global configuration mode. You are in
global configuration mode when the
prompt changes to Router(config)#.

xxxv
Getting Help
Table 2 How to Find Command Options (continued)
Command Comment
Router(config)# interface serial ? Enter interface configuration mode by
<0-6> Serial interface number specifying the serial interface that you
Router(config)# interface serial 4 ?
/
want to configure using the interface
Router(config)# interface serial 4/ ? serial global configuration command.
<0-3> Serial interface number
Enter ? to display what you must enter
Router(config)# interface serial 4/0 ?
<cr> next on the command line. In this
Router(config)# interface serial 4/0 example, you must enter the serial
Router(config-if)# interface slot number and port number,
separated by a forward slash.
When the <cr> symbol is displayed,
you can press Enter to complete the
command.
You are in interface configuration mode
when the prompt changes to
Router(config-if)#.
Router(config-if)# ? Enter ? to display a list of all the
Interface configuration commands: interface configuration commands
.
.
available for the serial interface. This
. example shows only some of the
ip Interface Internet Protocol config commands available interface configuration
keepalive Enable keepalive commands.
lan-name LAN Name command
llc2 LLC2 Interface Subcommands
load-interval Specify interval for load calculation for an
interface
locaddr-priority Assign a priority group
logging Configure logging for interface
loopback Configure internal loopback on an interface
mac-address Manually set interface MAC address
mls mls router sub/interface commands
mpoa MPOA interface configuration commands
mtu Set the interface Maximum Transmission Unit (MTU)
netbios Use a defined NETBIOS access list or enable
name-caching
no Negate a command or set its defaults
nrzi-encoding Enable use of NRZI encoding
ntp Configure NTP
.
.
.
Router(config-if)#

xxxvi
Getting Help
Command Comment
Router(config-if)# ip ? Enter the command that you want to
Interface IP configuration subcommands: configure for the interface. This
access-group Specify access control for packets
accounting Enable IP accounting on this interface
example uses the ip command.
address Set the IP address of an interface Enter ? to display what you must enter
authentication authentication subcommands
next on the command line. This
bandwidth-percent Set EIGRP bandwidth limit
broadcast-address Set the broadcast address of an interface example shows only some of the
cgmp Enable/disable CGMP available interface IP configuration
directed-broadcast Enable forwarding of directed broadcasts commands.
dvmrp DVMRP interface commands
hello-interval Configures IP-EIGRP hello interval
helper-address Specify a destination address for UDP broadcasts
hold-time Configures IP-EIGRP hold time
.
.
.
Router(config-if)# ip
Router(config-if)# ip address ? Enter the command that you want to
A.B.C.D IP address configure for the interface. This
negotiated IP Address negotiated over PPP
Router(config-if)# ip address
example uses the ip address command.
next on the command line. In this
example, you must enter an IP address
or the negotiated keyword.
A carriage return (<cr>) is not
displayed; therefore, you must enter
additional keywords or arguments to
complete the command.
Router(config-if)# ip address 172.16.0.1 ? Enter the keyword or argument that you
A.B.C.D IP subnet mask want to use. This example uses the
Router(config-if)# ip address 172.16.0.1
172.16.0.1 IP address.
example, you must enter an IP subnet
mask.
A <cr> is not displayed; therefore, you
must enter additional keywords or
arguments to complete the command.

xxxvii
Using the no and default Forms of Commands
Command Comment
Router(config-if)# ip address 172.16.0.1 255.255.255.0 ? Enter the IP subnet mask. This example
secondary Make this IP address a secondary address uses the 255.255.255.0 IP subnet mask.
<cr>
Router(config-if)# ip address 172.16.0.1 255.255.255.0 Enter ? to display what you must enter
example, you can enter the secondary
keyword, or you can press Enter.
A <cr> is displayed; you can press
Enter to complete the command, or
you can enter another keyword.
Router(config-if)# ip address 172.16.0.1 255.255.255.0 In this example, Enter is pressed to
Router(config-if)# complete the command.
Using the no and default Forms of Commands

Almost every configuration command has a no form. In general, use the no form to disable a function.
Use the command without the no keyword to reenable a disabled function or to enable a function that is
disabled by default. For example, IP routing is enabled by default. To disable IP routing, use the no ip
routing command; to reenable IP routing, use the ip routing command. The Cisco IOS software
command reference publications provide the complete syntax for the configuration commands and
describe what the no form of a command does.
Configuration commands can also have a default form, which returns the command settings to the
default values. Most commands are disabled by default, so in such cases using the default form has the
same result as using the no form of the command. However, some commands are enabled by default and
have variables set to certain default values. In these cases, the default form of the command enables the
command and sets the variables to their default values. The Cisco IOS software command reference
publications describe the effect of the default form of a command if the command functions differently
than the no form.
Saving Configuration Changes

Use the copy system:running-config nvram:startup-config command or the copy running-config
startup-config command to save your configuration changes to the startup configuration so that the
changes will not be lost if the software reloads or a power outage occurs. For example:
Router# copy system:running-config nvram:startup-config
Building configuration...
It might take a minute or two to save the configuration. After the configuration has been saved, the
following output appears:
[OK]
Router#
On most platforms, this task saves the configuration to NVRAM. On the Class A flash file system
platforms, this task saves the configuration to the location specified by the CONFIG_FILE environment
variable. The CONFIG_FILE variable defaults to NVRAM.

xxxviii
Filtering Output from the show and more Commands
Filtering Output from the show and more Commands

You can search and filter the output of show and more commands. This functionality is useful if you
need to sort through large amounts of output or if you want to exclude output that you need not see.
To use this functionality, enter a show or more command followed by the “pipe” character (|); one of the
keywords begin, include, or exclude; and a regular expression on which you want to search or filter (the
expression is case-sensitive):
command | {begin | include | exclude} regular-expression
The output matches certain lines of information in the configuration file. The following example
illustrates how to use output modifiers with the show interface command when you want the output to
include only lines in which the expression “protocol” appears:
Router# show interface | include protocol
FastEthernet0/0 is up, line protocol is up

Serial4/0 is up, line protocol is up
Serial4/1 is up, line protocol is up
Serial4/2 is administratively down, line protocol is down
Serial4/3 is administratively down, line protocol is down
For more information on the search and filter functionality, see the “Using the Cisco IOS Command-Line
Interface” chapter in the Cisco IOS Configuration Fundamentals Configuration Guide.
Finding Additional Feature Support Information

If you want to use a specific Cisco IOS software feature, you will need to determine in which Cisco IOS
software images that feature is supported. Feature support in Cisco IOS software images depends on
three main factors: the software version (called the “Release”), the hardware model (the “Platform” or
“Series”), and the “Feature Set” (collection of specific features designed for a certain network
environment). Although the Cisco IOS software documentation set documents feature support
information for Release 12.4 as a whole, it does not generally provide specific hardware and feature set
information.
To determine the correct combination of Release (software version), Platform (hardware version), and
Feature Set needed to run a particular feature (or any combination of features), use Feature Navigator.
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.
Software features may also have additional limitations or restrictions. For example, a minimum amount
of system memory may be required. Or there may be known issues for features on certain platforms that
have not yet been resolved (called “Caveats”). For the latest information about these limitations, see the
release notes for the appropriate Cisco IOS software release. Release notes provide detailed installation
instructions, new feature descriptions, system requirements, limitations and restrictions, caveats, and
troubleshooting information for a particular software release.

xxxix
Finding Additional Feature Support Information

xl
Service Selection Gateway Features Roadmap
First Published: May 2, 2005

Last Updated: May 9, 2006
This roadmap lists the features documented in the Cisco IOS Service Selection Gateway Configuration
Guide and maps them to the modules in which they appear.
Feature and Release Support

Table 3 lists Service Selection Gateway (SSG) feature support for the following Cisco IOS software
release trains:
• Cisco IOS Releases 12.2T, 12.3, and 12.3T
Only features that were introduced or modified in Cisco IOS Release 12.2(8)T or a later release appear
in the table. Not all features may be supported in your Cisco IOS software release.
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 lists only the Cisco IOS software release that introduced support for a given feature in a given
Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS
software release train also support that feature.

78-17497-01 1
Table 3 Supported SSG Features
Release Feature Name Feature Description Where Documented

Cisco IOS Releases 12.2T, 12.3, and 12.3T
12.2(8)T SSG Open Garden The SSG Open Garden feature enables you to use Cisco Configuring SSG for
SSG to implement open gardens, which are collections of Subscriber Services
Web sites or networks that subscribers can access as long
as they have physical access to the network. Subscribers
do not have to provide authentication information before
accessing the Web sites in an open garden.
SSG TCP Redirect The SSG TCP Redirect feature redirects certain packets, Configuring SSG TCP
which would otherwise be dropped, to captive portals that Redirection Features
can handle the packets in a suitable manner. For example,
packets sent upstream by unauthorized users are
forwarded to a captive portal that can redirect the users to
a login window. Similarly, if users try to access a service
to which they have not logged in, the packets are
redirected to a captive portal that can provide a service
login window.
Per-Session Firewall The SSG Per Session Firewall feature enables you to Configuring a
configure Cisco IOS software access control lists (ACLs) Per-Session Firewall
to prevent users, services, and pass-through traffic from
accessing specific IP addresses and ports.
12.2(11)T Initial SSG The Initial SSG Communication feature comprises initial Implementing SSG:
Communication tasks you need to perform to enable SSG on the router Initial Tasks
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.
RADIUS Profiles and SSG uses RADIUS Profiles and attributes for the RADIUS Profiles and
Attributes for SSG authentication, authorization, and accounting of Attributes for SSG
subscribers.
SSG Accounting The SSG Accounting feature allows a service provider to Configuring SSG
decide how to configure billing and accounting for its Accounting
users.
SSG Port-Bundle The SSG Port-Bundle Host Key feature enhances Implementing SSG:
Host-Key communication and functionality between the Service Initial Tasks
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.
SSG Prepaid Tariff The SSG Prepaid Tariff Switching feature allows changes Configuring SSG
Switching in tariffs during the lifetime of a connection. Accounting

2 78-17497-01
Table 3 Supported SSG Features (continued)

12.2(13)T SSG Accounting Update The SSG Accounting Update Interval Per Service feature Configuring SSG
Interval Per Service allows the service provider to configure different Accounting
accounting intervals for different services.
SSG AutoDomain The SSG AutoDomain feature allows Service Selection Configuring SSG to
Gateway (SSG) to authenticate subscribers automatically Authenticate Subscribers
in the service domain. Automatically in the
Service Domain
SSG Autologon Using The SSG AutoLogon Using Proxy RADIUS feature Configuring SSG to Serve
Proxy RADIUS enables SSG to act as a RADIUS proxy for non-SSD as a RADIUS Proxy
clients whose Access-Requests do not contain VSAs.
SSG Hierarchical The SSG Hierarchical Policing feature ensures that a Configuring SSG
Policing subscriber does not utilize additional bandwidth for Hierarchical Policing
overall service or for a specific service that is outside the
bounds of the subscriber's contract with the service
provider.

78-17497-01 3

12.3(4)T Postpaid Tariff Switching The Postpaid Tariff Switching for SSG feature allows Configuring SSG
for SSG changes in tariffs during the lifetime of a connection. Accounting
PPP Subscriber Access The PPP subscriber access feature supports PPP as a Configuring SSG to
subscriber access protocol. Authenticate PPP
Subscribers
PTA-MD Exclusion List The PTA-MD Exclusion List feature allows you to create Configuring SSG to
a set of domains that are excluded from normal SSG Authenticate PPP
structured username processing. Subscribers
SSG AAA Server Group This feature allows you to configure multiple AAA Configuring SSG to Serve
for Proxy RADIUS servers. You can configure each remote RADIUS server as a RADIUS Proxy
with timeout and retransmission parameters. SSG will
perform failover among the servers in the predefined
group.
SSG Autologoff The SSG Autologoff feature supports methods to log Configuring SSG to Log
subscribers out of SSG. Off Subscribers
SSG Direction SSG implements service selection through selective Implementing SSG:
Configuration for routing of IP packets to destination networks on a Initial Tasks
Interfaces and Ranges 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.
SSG EAP Transparency In 802.1x WLAN deployments, SSG acts as a RADIUS Configuring SSG to Serve
Proxy during Extensible Authentication Protocol (EAP) as a RADIUS Proxy
authentication between a WLAN AP and the
corresponding AAA server. Using SSG as a RADIUS
Proxy in 802.1x deployments enables WLAN users to
access SSG functionality after they have connected to the
AP.
SSG Prepaid The SSG Prepaid Enhancements feature adds support for Configuring SSG
Enhancements prepaid tariff switching, postpaid tariff switching, and Accounting
simultaneous volume- and time-based prepaid billing to
the existing SSG Prepaid feature.
SSG Prepaid Idle Timeout The SSG Prepaid Idle Timeout feature enables SSG to Configuring SSG
return residual quota to the billing server from services Accounting
that a user is logged into but not actively using.
SSG Proxy for This feature enables service selection in CDMA2000 Configuring SSG to Serve
CDMA2000 networks through enhancements to the SSG RADIUS as a RADIUS Proxy
Proxy functionality.
SSG Service Profile The Service Profile Cache feature enables SSG to use a Configuring SSG for
Caching cached copy of a service profile instead of downloading Subscriber Services
the profile from a RADIUS server every time a user logs
on to the service.
SSG Suppression of The SSG Suppression of Unused Accounting Records Configuring SSG
Unused Accounting feature allows you to turn off unneeded Service Selection Accounting
Records Gateway (SSG) accounting records.

4 78-17497-01

12.3(7)T SSG Service Logon The SSG Service Logon Enhancements feature enables Configuring SSG for
Enhancements SSG to deliver services to a subscriber after receiving Subscriber Services
valid authentication information.
SSG Transparent The SSG Transparent Autologon feature enables Service Configuring SSG to
Autologon Selection Gateway (SSG) to authenticate and authorize a Authenticate Subscribers
user on the basis of the source IP address of packets with Transparent
received from the user. Autologon
DNS Redirection The SSG DNS Redirection feature enables you to match Configuring Default DNS
a domain name server (DNS) request to the appropriate Redirection
domain name service, based on attributes of the user
requesting the service.
12.3(8)T SSG Interface SSG interface redundancy allows services to be Implementing SSG:
Redundancy associated with more than one interface to protect against Initial Tasks
link failures.
12.3(11)T SSG Default Quota for The SSG Default Quota for Prepaid Billing Server Configuring SSG
Prepaid Billing Server Failure feature enables SSG to be configured to allocate Accounting
Failure a default quota when the prepaid server fails to respond
to an authorization request.
12.3(14)T Extended Prepaid Tariff The Extended Prepaid Tariff Switch for SSG feature is Configuring SSG
Switching for SSG used to measure the usage of specific services at various Accounting
times, even when the monetary value of the volume quota
does not change at the time of tariff switching.
MAC-Address-Based The MAC-Address-Based Authentication for SSG Configuring SSG for
Authentication for SSG feature allows a service provider to authorize subscriber MAC-Address-Based
access to services by the subscriber's MAC address, thus Authentication
eliminating the need for explicit user logins between
client power cycles.
On-Demand IP Address The SSG On-Demand IP Address Renewal feature Configuring SSG for
Renewal for SSG enables service providers to manage the Dynamic Host On-Demand IP Address
Configuration Protocol (DHCP) pool from which a Renewal
subscriber's IP address is assigned.
SSG L2TP Dial-Out The L2TP Dial-Out feature provides mobile users with a Configuring SSG for
way to securely connect to their SOHOs through the Subscriber Services
PSTN.
SSG Support for The SSG Support for Subnet-Based Authentication Configuring SSG Support
Subnet-Based feature allows a service provider to identify subscribers for Subnet-Based
Authentication to services by their subnet, rather than by a subscriber's Authentication
IP address.

78-17497-01 5

6 78-17497-01
Overview of SSG
The Cisco Service Selection Gateway (SSG) is a Cisco IOS software feature set that works with the
Cisco Subscriber Edge Services Manager (SESM) and other components to provide a subscriber edge
services solution. SESM is used to deliver on-demand subscriber services across any SSG-enabled
network. SSG provides on-demand service enforcement within the Cisco network. As part of a
subscriber edge services solution, SSG provides subscriber authentication, service selection, and service
connection capabilities to subscribers of Internet services.
Module History
This module was first published on May 2, 2005, and last updated on May 2, 2005.
Contents
• Prerequisites for SSG, page 7
• Restrictions for SSG, page 7
• Information About SSG, page 8
• Where to Go Next, page 14
• Additional References, page 14
Prerequisites for SSG

• A Cisco router running a version of Cisco IOS software that supports Service Selection Gateway
(SSG).
• An implementation of Cisco Subscriber Edge Services Manager (SESM).
• A RADIUS or Directory-based authentication system.
Restrictions for SSG

SSG does not process multicast packets.

78-17497-01 7
Overview of SSG
Information About SSG

Before you begin to configure SSG, you should understand the following concepts:
• Overview of Cisco’s Subscriber Edge Services Solution, page 8
• Benefits of Using SSG, page 9
• Components of a Subscriber Edge Services Solution, page 10
• Subscriber Edge Services Network Architecture, page 12
• How Does SSG Work?, page 13
• SSG Network Deployments, page 13
• SSG Supported Access Protocols, page 13
Overview of Cisco’s Subscriber Edge Services Solution

The Cisco Service Selection Gateway (SSG) and Cisco Subscriber Edge Services Manager (SESM) are
both components of the Cisco subscriber edge services solution. Cisco SESM is a product portfolio used
for delivering on-demand subscriber services across any SSG-enabled network. SSG is the Cisco IOS
feature set that serves as an access gateway that controls user access at the edge of the IP network.
A subscriber edge services solution is used to control user experience at the network edge. As an
example, consider a business user that is accessing IP services via a wireless or other broadband
connection in a hotel. SSG, in conjunction with SESM, redirects the unauthenticated subscriber’s web
browser to a walled garden, which might feature local weather and general hotel information. Upon
registration, the subscriber may have expanded access to billing information, concierge services,
printing services, and general Internet access. The subscriber edge services solution enables a service
provider to advertise and offer on-demand, pay-per-use IP services based on location and type of access
device.
Figure 1 shows how SSG and SESM manage subscriber access to network services.

8 78-17497-01
Overview of SSG
Figure 1 Delivering Network Services with Cisco SESM and SSG
SESM
Registration - Personalized content
- List of subscribed services
- Access to walled gardens
- On-demand, billable services
Mobile
Access Wi-Fi
networks DSL
Laptop Cable
PDA Ethernet
Cisco SSG
Mobile
Walled gardens Internet
Reservations Weather Flight info
Basic
Video Voice
Internet
Premium
services
127101
Corporate
VPN
A subscriber edge services solution provides robust, highly scalable subscriber authentication, service
selection, and service connection capabilities to subscribers in broadband and mobile environments.
Benefits of Using SSG

Service providers can generate revenue in two ways: by providing access technology and by providing
network access. In a traditional service-provider environment, the service and access technologies are
tightly joined, which makes it difficult to roll out new services, and restricts the service provider to flat
billing based on the access technology.
SSG separates the service and access technologies, giving subscribers a selection of services from which
to choose, and enabling service providers to implement service- and usage-based billing.
SSG, as part of a subscriber edge services solution, provides the following benefits:
Subscriber Authentication and Authorization

Subscriber Edge Services support user authentication to standard user databases. Subscriber and service
profiles may be maintained in RADIUS servers and directory servers and may be owned by different
entities. Single signon is supported to remove redundant authentication steps and provide subscribers
with streamlined access to authorized services.

78-17497-01 9
Overview of SSG
Web Portals
Subscriber Edge Services support web browser (HTTP) redirection or “captivation” of unauthenticated
users to specific web pages. Web pages may be customized and personalized according to device,
connection type, location, and other characteristics. This capability supports branding and targeted
point-of-sale messaging. Service redirection and captivations are available to raise system messages or
advertising at any time during a session.
Subscriber Self-Care
Subscriber Edge Services support subscriber account self-management. Subscribers can change their
own account details (such as address, phone number, and password) and create and manage
sub-accounts. Account self-registration and service self-subscription allow subscribers to fill in their
initial account details and sign up for new services without assistance. Self-care improves customer
satisfaction and reduces operational expenses.
Web-based Service Selection

SSG with SESM allows a service provider to create a branded web portal that presents subscribers with
a menu of services. Subscribers can log on to and disconnect from different services using a web
browser. This web-based service selection method takes advantage of the wide availability of web
browsers and eliminates problems related to client software (such as license fees, distribution logistics,
and an increased customer support burden).
Billing Flexibility for Service Providers

Cisco SSG allows subscribers to dynamically select and modify services. SSG monitors user
connections, service logon and logoff, and user activity per service. By providing per-connection
accounting, SSG enables service providers to bill subscribers for connection time, speed, and services
used rather than charging a flat rate. Using SSG, service providers can also package sell prepaid services.
Open Access
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 competing Internet
service providers (ISPs). SSG can enable access providers to deploy services through multiple ISPs,
allowing the consumer to choose their preferred ISP.
Flexibility and Convenience for Subscribers

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 available services.
Components of a Subscriber Edge Services Solution

The following sections describe the components of a subscriber edge services solution:
• SSG, page 11
• SESM, page 11
• AAA Server, page 11
• Services, page 11

10 78-17497-01
Overview of SSG
SSG
SSG is the Cisco IOS feature set that controls user access at the edge of an IP network. SSG is deployed
at network access control points, and subscribers connect to service destinations through SSG. The role
of SSG is to identify and authenticate subscribers and then load a subscriber-specific profile that governs
the network services that the subscriber is entitled to access.
SESM
SESM is a software toolkit that interacts with SSG to control the user experience at the network edge by
providing a set of web-based interactive applications. These applications interact with the user to obtain
identity and credentials for authentication and payment. SESM web applications also interact with the
user to provide service selection, subscriber account self-management, and self-subscription. These
applications can be personalized, localized, and customized to display advertisements and notifications
according to where the user connects to the network and with which device.
AAA Server
An authentication, authorization, and accounting (AAA) server is used in a subscriber edge services
solution as the data repository for service, subscriber, and policy information. SSG is designed to work
with two types of servers: RADIUS-based AAA servers that accept vendor-specific attributes (VSAs)
and Lightweight Directory Access Protocol (LDAP) directories.
Note In order to use an LDAP directory, SSG must be used with SESM, and SESM must be configured for
LDAP mode. For information on creating and maintaining subscriber, service, and policy information in
an LDAP directory, refer to the Cisco Subscriber Management Guide.
Services
The term services means different things in different contexts. At the most fundamental and technical
level, a service is defined in networking terms as a network destination: a subset of the service network.
From a router perspective, a network destination is defined in terms of interfaces, next-hop definitions,
and IP definitions.
Services have attributes. Some of these attributes refer to whether and how the user must be
authenticated to access the services; other service attributes allow access filters and determine usage
limits and quotas. The collection of attributes is known as a service profile.
At the user level, services may be described in more businesslike terms: free services versus fee-based
services, gold service versus bronze, service selection, subscriber self provisioning, and so on. From the
service provider perspective, a subscriber is defined by means of a user profile, which determines the
services to which the subscriber is entitled.
These are examples of services that providers can offer:
• VPN services—Level 2 and Level 3 VPNs, irrespective of the type of transport. The services may
include telecommuter access to corporate, or equal access to a number of different ISPs from an
access provider.
• Filter services—Services that are implemented in the edge device or some inline device that limits
access in some way, like firewalls, SPAM filters, virus filters and others.
• Prepaid services

78-17497-01 11
Overview of SSG
• Content Service Gateways (CSGs):—Used to charge per page or unit of content (such as mp3 or gif
files).
• Tiered Internet access—(for example bronze, silver, or gold)
• Dynamic bandwidth on demand
• Integrated voice and data
• Internet gaming and multimedia services
• Distance learning services
• Video on demand
• Peer-to-peer application control (for example, constraining bandwidth available for music
downloads)
• Higher bandwidth for premium users, irrespective of applications
Subscriber Edge Services Network Architecture

Figure 2 illustrates how the components of a subscriber edge services network work together.
Figure 2 Service Selection Gateway Topology
AAA Directory
Server
PC SESM
DSL Corporate
VPN
WAP
Internet
SSG
GGSN
PDA Gaming
Wireless LAN Open

Notebook garden
127102
Subscriber access media Services selection Services

12 78-17497-01
Overview of SSG
Subscribers access the SESM web portal application using any web browser on a variety of devices, such
as a desktop computer over DSL, a cellular phone over GPRS or CDMS, or a PDA over a WLAN.
Depending on how SSG has been configured, unauthenticated users can either be forwarded to the SESM
captive portal or automatically logged into the network. Service providers can thus use the SSG feature
set of the router to design a service selection access network.
Subscribers can use SESM to manager their accounts, subscribe to new services, and select those
services that they want to use. Service providers can use a subscriber edge services solution to offer and
advertise value-added services and to associate these services with their brand identities.
How Does SSG Work?

A licensed version of SSG works with SESM to present to users a menu of 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 only the connect time and services used,
rather than by charging a flat rate.
For instance, when SSG is used with SESM, the user opens an HTML browser and is redirected to the
SESM web server application. SSG always allows access to a single IP address or subnet—referred to
as the default network—where SESM is typically located. SESM prompts the user for a username and
password.
SESM forwards the user’s logon information to SSG, which forwards the information to either the AAA
server, or to the RADIUS-DESS Proxy (RDP) component of SESM for LDAP authentication. If the user
is not valid, the AAA server or RDP sends an Access-Reject message. If the user is valid, the AAA server
or RDP sends an Access-Accept message with information specific to the user’s profile about which
services the user is authorized to use. SSG logs the user in and sends the response to SESM.
Depending on the contents of the Access-Accept or Access-Reject response, SESM presents a menu of
authorized services, one or more of which is selected by the user. SSG then creates an appropriate
connection for the user and, optionally, starts RADIUS accounting for the connection.
SSG Network Deployments

Service selection technology can be used in many types of access technology; for example:
• Broadband cable
• Digital Subscriber Line (DSL)
• Ethernet to home or office
• Public Wide Area Network (PWLAN)
• Mobile wireless, including General Packet Radio Service (GPRS) and Code Division Multiple
Access (CDMA)
SSG Supported Access Protocols

SSG supports the following protocols and encapsulations:
• Point-to-Point Protocol (PPP), including PPP over Ethernet (PPPoE), PPP over ATM (PPPoA), and
PPP over Layer 2 Tunnel Protocol (PPPoL2TP)
• Routed Bridged Encapsulation (RBE) and RFC1483 IP

78-17497-01 13
Overview of SSG
Where to Go Next
SSG accepts traffic on the following interface types:

• ATM PVCs and subinterfaces
• Ethernet interfaces and subinterfaces
• Logical interfaces such as GRE and IPinIP
• Packet over SONET (POS) interfaces
• Serial and channelized interfaces
Where to Go Next
SSG configuration tasks are described in the following modules:
• Implementing SSG: Initial Tasks—this process explains how to enable SSG and establish
communication with the AAA server and SESM.
• Configuring SSG to Serve as a RADIUS Proxy—this module describes the types of deployments
that use SSG as a RADIUS proxy and how to configure them.
• Configuring SSG to Authenticate Subscribers—the following processes explain how to configure
SSG to authenticate subscribers according to the method of subscriber login.
– Configuring SSG to Authenticate Web Logon Subscribers
– Configuring SSG to Authenticate PPP Subscribers
– Configuring SSG to Authenticate Subscribers with Transparent Autologon
– Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
– Configuring SSG for On-Demand IP Address Renewal
– Configuring SSG Support for Subnet-Based Authentication
– Configuring SSG for MAC-Address-Based Authentication
• Configuring SSG for Subscriber Services—this process describes how to configure SSG to create
services and allow subscribers to use them.
• Configuring SSG to Log Off Subscribers—this process explains how to configure methods of
subscriber logoff, such as SSG autologoff and timeouts.
• Configuring SSG Accounting—this process explains how to configure SSG support for subscriber
accounting and billing, including per-service accounting, broadcast accounting, and prepaid
services.
• RADIUS Profiles and Attributes for SSG—this module describes RADIUS profiles and their
attributes.
Additional References
The following sections provide references related to configuring SSG.

14 78-17497-01
Overview of SSG
Related Documents
Related Topic Document Title
Configuring SESM Cisco Subscriber Edge Services Manager documentation.
RADIUS commands Cisco IOS Security Command Reference, Release 12.4
RADIUS configuration tasks “Configuring RADIUS” chapter in the Cisco IOS Security
Configuring L2TP Cisco IOS Dial Technologies Configuration Guide, Release 12.4
Cisco IOS Dial Technologies Command Reference, Release 12.4
Technical Assistance
Description Link
Technical Assistance Center (TAC) home page, http://www.cisco.com/public/support/tac/home.shtml
containing 30,000 pages of searchable technical
content, including links to products, technologies,
solutions, technical tips, and tools. Registered
Cisco.com users can log on from this page to access
even more content.

78-17497-01 15
Overview of SSG

16 78-17497-01
Implementing SSG: Initial Tasks
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.
Module History
Finding Feature Information in This Module

Your Cisco IOS software release may not support all features. To find information about feature support
and configuration, use the “Feature Information for Implementing SSG” section on page 40.
Contents
• Prerequisites for Implementing SSG, page 17
• Restrictions for Implementing SSG, page 18
• How to Establish Initial SSG Communication, page 18
• Configuration Examples for Establishing Initial SSG Communication, page 35
• Where To Go Next, page 39
• Feature Information for Implementing SSG, page 40
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).

78-17497-01 17
Restrictions for Implementing SSG
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, page 18
• System Resource Cleanup When SSG Is Unconfigured, page 19
• Configuring the Default Network, page 25
• Configuring SSG Communication with SESM:
– Configuring SSG-SESM API Communication, page 26
– Configuring SSG Port-Bundle Host-Key Functionality, page 27
• Configuring SSG to AAA Server Interaction, page 33
• Troubleshooting Initial SSG Communication, page 35
Enabling SSG
Perform this task to enter global configuration and enable SSG on the router.
Note This task must be performed before any other SSG functionality can be configured.
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.

18 78-17497-01
SUMMARY STEPS
1. enable
2. configure terminal
3. ip cef
4. ssg enable
DETAILED STEPS
Command or Action Purpose

Step 1 enable Enables privileged EXEC mode.
• Enter your password if prompted.
Example:
Router> enable
Step 2 configure terminal Enters global configuration mode.
Example:
Router# configure terminal
Step 3 ip cef Enables global IP CEF.
Example:
Router(config)ip cef
Step 4 ssg enable Enables SSG.
Example:
Router(config)# ssg enable
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:
• Interface Direction, page 20
• Uplink Interface Redundancy Overview, page 20
• Downlink Interface Redundancy Overview, page 20
• SSG Uplink Interface Redundancy Topologies, page 21
• Restrictions, page 22

78-17497-01 19
Perform the following tasks to configure SSG interfaces:

• Setting SSG Interface Direction for an Individual Interface, page 23
• Setting the Direction on an ATM Subinterface (with PVC or PVC Range), page 23
• Verifying SSG Interface Binding, page 25
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 service is configured for multiple uplink interfaces, downstream traffic is allowed on all of the
interfaces for any service bound to even one of those interfaces.
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 on page 23
Downlink Interface Redundancy Overview

Subscriber traffic can be received by SSG on any of the downlink configured interfaces, which allows
for downlink interface redundancy.

20 78-17497-01
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 on page 27.
SSG Uplink Interface Redundancy Topologies

The SSG Interface Redundancy feature supports uplink interface redundancy in the following network
topologies:
• Multiple Next Hops per Service, page 21
• Multiple Uplink Interfaces with a Single Next Hop, page 21
• Multiple Uplink Interfaces with No Next Hop, page 22
• Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops, page 22
Multiple Next Hops per Service
Figure 3 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 3 Multiple Next Hops per Service: Sample Topology
Next hop 1
Uplink 1
SSG Service
103656
Uplink 2
Next hop 2
Multiple Uplink Interfaces with a Single Next Hop
Figure 4 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.

78-17497-01 21
Figure 4 Multiple Uplink Interfaces with a Single Next Hop: Sample Topology
Uplink 1
SSG Next hop Service
103657
Uplink 2
Multiple Uplink Interfaces with No Next Hop
interfaces that are directly connected to the service.
Figure 5 Multiple Uplink Interfaces with No Next Hop: Sample Topology
Uplink 1
SSG Service
103658
Uplink 2
Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops
Figure 6 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 6 Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops:
Sample Topology
Uplink 1
103659
SSG Service
Uplink 2
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.

22 78-17497-01
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 interface
Please use ‘no ssg direction downlink’ to clear the previous bind direction
Setting SSG Interface Direction for an Individual Interface

Perform this task to configure interface direction for an individual interface.
SUMMARY STEPS
1. interface type number

2. ssg direction {downlink | uplink [member group-name]}
3. exit
4. Repeat steps 1 to 3 for each interface for which you want to configure direction.
DETAILED STEPS

Step 1 interface type number Specifies an interface and enters interface configuration
mode.
Example:
Router(config)# interface FastEthernet 1/0
Step 2 ssg direction {downlink | uplink [member Sets the direction of the interface.
group-name]}
• An uplink interface is an interface to services; a
downlink interface is an interface to subscribers.
Example:
Router(config-if)# ssg direction downlink
• The member option specifies that the interface is a
member of a group of uplink interfaces that reach the
same service. Use this option to group redundant uplink
interfaces and to configure SSG to treat redundant
uplink interfaces similarly.
Step 3 exit (Optional) Exits to global configuration mode.
Example:
Router(config-if)# exit
Step 4 Repeat steps 1 to 3 for each interface for which you want to configure direction.
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,
page 23). However, if the point-to-point ATM subinterface contains a PVC range, this will result in

78-17497-01 23
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. interface atm interface-number.subinterface-number {mpls | multipoint | point-to-point}

2. ssg direction {downlink | uplink [member group-name]}
3. pvc <vpi>/vci
or
4. range [range-name] pvc start-vpi/start-vci end-vpi/end-vci
DETAILED STEPS

Step 1 interface atm Specifies a subinterface and enters subinterface
interface-number.subinterface-number {mpls | configuration mode.
multipoint | point-to-point}
Example:
Router(config)# interface ATM 1/0.1
point-to-point
Step 2 ssg direction {downlink | uplink [member Sets the direction of the subinterfaces.
group-name]}
• An uplink interface is an interface to services; a
downlink interface is an interface to subscribers.
Example:
Router(config-subif)# ssg direction downlink
Step 3 pvc vpi/vci Defines a PVC
• Use this command to define the permanent virtual
Example: connection (PVC).
Router(config-subif)# pvc 1/32
Step 4 range [range-name] pvc start-vpi/start-vci Defines a PVC range.
end-vpi/end-vci
• Use this command if a range was not already defined.
You can also use this command after the ssg direction
Example: command, with the same effect.
Router(config-subif)# range MyRange pvc 1/32
1/42

24 78-17497-01
Verifying SSG Interface Binding

Perform this task to verify the binding of SSG interfaces.
SUMMARY STEPS
1. show ssg interface [brief] [interface-type interface-number]
DETAILED STEPS

Step 1 show ssg interface [brief] [interface-type Displays information about SSG interfaces.
interface-number]
Example:
Router# show ssg interface brief
Example
The following examples of output for the show ssg interface command show information about SSG
interface binding:
Router# show ssg interface
Interface: Ethernet1/1
Bind Direction: Downlink
Binding Type: Static
Interface: ATM4/0.40
Bind Direction: Downlink
Interface: ATM4/0.140
Bind Direction: Uplink
Services bound: NONE
Router# show ssg interface brief
Interface Direction Binding Type

Ethernet1/1 Downlink Static
ATM4/0.40 Downlink Static
ATM4/0.140 Uplink Static
Configuring 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.

78-17497-01 25
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 On SSG platforms that support PXF forwarding engine, SSG typically forwards packets to and from the
default network through the router’s PXF forwarding engine. However, SSG also forwards default
network traffic through the route processor (RP) as follows:
Packets from a User and Destined for the Default Network

If the port-bundle host-key is:
• Enabled—SSG forwards the packets through the RP.
• Disabled—SSG forwards the packets through the PXF forwarding engine.
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:
• The port-bundle host-key is enabled.
• The port-bundle host-key is disabled, TCP is the transport protocol, and the packets are associated
with an active TCP redirect mapping.
Otherwise, SSG forwards the packets through the PXF forwarding engine.
SUMMARY STEPS
1. ssg default-network ip-address mask
DETAILED STEPS

Step 1 ssg default-network ip-address mask Sets the IP address or subnet that users are able to
access without authentication.
Example: • Typically, this is the address where the Cisco
Router(config)ssg default-network 10.10.1.2 SESM resides.
255.255.255.255
• A mask provided with the IP address specifies
the range of IP addresses that users are able to
access without authentication.
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.

26 78-17497-01
SUMMARY STEPS
1. ssg radius-helper key

2. ssg radius-helper [auth-port UDP-port-number] [acct-port UDP-port-number]
3. ssg radius-helper [access-list]
4. ssg radius-helper [validate]
DETAILED STEPS

Step 1 ssg radius-helper key Sets the shared secret key between SSG and SESM.
Example:
Router(config)# ssg radius-helper key MyKey
Step 2 ssg radius-helper [auth-port UDP-port-number] Specifies the port on which SSG will listen for SESM
[acct-port UDP-port-number] commands (SSG is the server). The default port
number for authentication packets is 1645, and the
Example: default port number for accounting packets is 1646.
Router(config)# ssg radius-helper [auth-port 1645]
[acct-port 1646]
Step 3 ssg radius-helper access-list (Optional) Specifies the access list to be applied to
traffic from SESM.
Example:
Router(config)# ssg radius-helper [access-list]
Step 4 ssg radius-helper validate (Optional) Enables the validation of SESM IP
addresses.
Example: • SSG will only accept commands from validated
Router(config)# ssg radius-helper validate IP addresses.
Configuring SSG Port-Bundle Host-Key Functionality

Before you configure the SSG Port-Bundle Host-Key (PBHK) feature, you should understand the
following concepts:
• Port-Bundle Host-Key Mechanism, page 28
• Port-Bundle Length, page 28
• Benefits of SSG Port-Bundle Host-Key, page 29
• Prerequisites for SSG Port-Bundle Host-Key, page 30
• Restrictions for SSG Port-Bundle Host-Key, page 30
Perform the following tasks to configure SSG Port-Bundle Host-Key functionality
• Configuring the SSG Port-Bundle Host-Key, page 30 (required
• Verifying SSG Port-Bundle Host-Key Configuration, page 32 (optional)

78-17497-01 27
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 4 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.
Table 4 Subscriber IP VSA Description
Attr ID Vendor ID Sub Attr ID and Type Attr Name Sub Attr Data
26 9 250 Account-Info Subscriber IP S<subscriber-ip-address>[:<port-bundle-number>
]
• S—Account-Info code for subscriber IP.
• <subscriber IP address>:<port-bundle
number>—The port-bundle number is only
used if the SSG Port-Bundle Host-Key feature
is configured.
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.

28 78-17497-01
Table 5 Port-Bundle Lengths and Resulting Port-per-Bundle and Bundle-per-Group Values
Port-Bundle Length Number of Ports Number of Bundles per Group

(in bits) per Bundle (and per SSG Source IP Address)
0 1 64512
1 2 32256
2 4 16128
3 8 8064
4 (default) 16 4032
5 32 2016
6 64 1008
7 128 504
8 256 252
9 512 126
10 1024 63
Note For each SESM server, all connected SSGs must have the same port-bundle length, which must
correspond to the configured value given in the SESM server’s BUNDLE_LENGTH argument. If you
change the port-bundle length on an SSG, be sure to make the corresponding change in the SESM
configuration.
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.

78-17497-01 29
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 SSG source IP addresses configured with the source ip command must be routable by SESM. This is the
IP addresses that SESM will receive for subscriber traffic.
Restrictions for SSG Port-Bundle Host-Key

The SSG Port-Bundle Host-Key feature has the following restrictions:
• The SSG Port-Bundle Host-Key feature must be enabled on all SSGs connected to SESM. The
port-bundle length should also be the same on all SSGs and SESM.
• The SSG Port-Bundle Host-Key feature can be enabled or disabled only when there are no active
SSG host objects present.
• The port-bundle length can only be changed when there are no active SSG host objects present.
• Overlapping subscriber IP addresses are supported only for hosts reachable via routed point-to-point
interfaces.
• Overlapping IP users cannot be connected to the same service or to different services that are bound
to the same uplink interface or interface group.
• For each SESM server, all connected SSGs must have the same port-bundle length.
• RFC 1483 or local bridged or routed clients cannot have overlapping IP addresses, even across
different interfaces.
• When the SSG Port-Bundle Host-Key is not configured, SSG local forwarding enables SSG to
forward packets locally between any SSG hosts. However, when the SSG Port-Bundle Host-Key
feature is configured, local forwarding works only between hosts that are connected to at least one
common service.
• The SSG Port-Bundle Host-Key feature enables certain subscribers to have overlapping IP
addresses. This binds subscribers to their respective downlink interfaces. Traffic from a user is not
accepted if it arrives on any other interface. To enable subscriber-side interface redundancy when
SSG port-bundle host-key functionality is configured and there are no overlapping IP host addresses,
you must disable overlapping IP address support (and hence, the subscriber binding to the interface).
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. ssg port-map
2. destination range port-range-start to port-range-end [ip ip-address]
3. destination access-list access-list-number

30 78-17497-01
4. source ip {ip-address | interface}

5. length bits
6. no host overlap
7. exit
DETAILED STEPS

Step 1 ssg port-map Enables the SSG port-bundle host-key feature and enables
ssg-port-map configuration mode.
Example:
Router(config)# ssg port-map
Step 2 destination range port-range-start to Identifies packets for port-mapping by specifying the TCP
port-range-end [ip ip-address] port range to compare against the subscriber traffic.
• If the destination IP address is not configured, a default
Example: network must be configured and routable from SSG in
Router(config-ssg-portmap)# destination range order for this command to be effective.
8080 to 8081
• If the destination IP address is not configured, any
traffic going to the default network with the destination
port will fall into the destination port range and will be
port mapped.
• You can use multiple entries of the destination
access-list and destination range commands. The port
ranges and access lists are checked against the
subscriber traffic in the order in which they were
defined.
Step 3 destination access-list access-list-number Identifies packets for port-mapping by specifying an access
list to compare against the subscriber traffic. Port map will
be applied to traffic matching the mentioned access list.
Example:
Router(config-ssg-portmap)# destination • You can use multiple entries of the destination
access-list 100 access-list and destination range commands. The port
ranges and access lists are checked in the order in
which they are defined.
Step 4 source ip {ip-address | interface} Specifies an SSG source IP address. If you specify an
interface instead of an IP address, SSG uses the main IP
address of the specified interface.
Example:
Router(config-ssg-portmap)# source ip 10.0.50.1 • You can use multiple entries of the source ip command.
• All SSG source IP addresses configured using the
source ip command must be routable in the
management network where SESM resides.

78-17497-01 31

Step 5 length bits Modifies the port-bundle length, in bits, used to determine
the number of ports per bundle and the number of bundles
per group. Default value is 4. A value of ‘n’ will result in
Example:
Router(config-ssg-portmap)# length 5
2^n ports per bundle.
Step 6 no host overlap Disables SSG support of overlapping host IP addresses.
• Use this command to enable subscriber-side interface
Example: redundancy when SSG port-bundle host-key
Router(config-ssg-portmap)# no host overlap functionality is configured and there are no overlapping
IP host addresses.
Verifying SSG Port-Bundle Host-Key Configuration

Perform this task to verify SSG port-bundle host-key configuration and operation.
SUMMARY STEPS
1. show running-config
2. show ssg port-map status [free | inuse | reserved]
3. show ssg port-map ip ip-address port port-number
DETAILED STEPS
Step 1 To verify the SSG Port-Bundle Host-Key configuration, use the show running-config command in
privileged EXEC mode.
Step 2 To display a summary of all port-bundle groups, use the show ssg port-map status command with no
keywords:
Router# show ssg port-map status
Bundle-length = 4
Bundle-groups:-
IP Address Free Bundles Reserved Bundles In-use Bundles

70.13.60.2 4032 0 0
Use 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 inuse
Bundle-group 70.13.60.2 has the following in-use port-bundles:
Port-bundle Subscriber Address Interface
64 10.10.3.1 Virtual-Access2
Step 3 To display information about a specific port bundle, use the show ssg port-map ip command:
Router# show ssg port-map ip 70.13.60.2 port 64
State = IN-USE

32 78-17497-01
Subscriber Address = 10.10.3.1

Downlink Interface = Virtual-Access2
Port-mappings:-
Subscriber Port: 3271 Mapped Port: 1024

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. ssg service-password password
DETAILED STEPS
Step 1 ssg service-password password Sets the password used to authenticate the SSG with
the local AAA server while downloading service
profiles.
Example:
Router(config)# ssg service-password password • This value must match the value configured for
the AAA server service profiles.
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. show ssg connection ip-address service-name [interface]

2. show ssg host [ip-address [interface]
3. show ssg port-map ip ip-address port port-number
4. show ssg port-map status [free | reserved | inuse]

78-17497-01 33
5. show ssg interface [interface | brief]

6. show ssg summary
7. clear ssg connection ip-address service-name [interface]
8. clear ssg host ip-address interface
DETAILED STEPS

Step 1 show ssg connection ip-address service-name (Optional) Displays the connections of a given host and a
[interface] service name.
Example:
Router# show ssg connection 19.1.1.19 InstMsg
Step 2 show ssg host [ip-address [interface] | (Optional) Displays the information about a subscriber and
username] current connections of the subscriber.
Example:
Router# show ssg host 10.3.1.1
Step 3 show ssg port-map ip ip-address port (Optional) Displays the following information about a port
port-number bundle:
• Port maps in the port bundle
Example:
Router# show ssg port-map ip 10.13.60.2 port 64
• Subscriber’s IP address
• Interface through which the subscriber is connected
Step 4 show ssg port-map status [free | reserved | (Optional) Displays information on port-bundle groups,
inuse] including the following:
• List of port-bundle groups
Example:
Router# show ssg port-map status
• Port-bundle length
• Number of free, reserved, and in-use port bundles in
each group
Step 5 show ssg interface [interface | brief] (Optional) Displays information about SSG interfaces.
• Use this command without any keywords or arguments
Example: to display information about all SSG interfaces.
Router# show ssg interface atm 3/0.10
Step 6 show ssg summary (Optional) Displays a summary of the SSG configuration.
• Use this command to display information such as which
Example: SSG features are enabled, how many users are active,
Router# show ssg summary how many services are active, and what filters are
active.

34 78-17497-01
Configuration Examples for Establishing Initial SSG Communication

Step 7 clear ssg connection ip-address service-name (Optional) Removes the connections of a given host and a
[interface] service name.
Example:
Router# clear ssg connection 10.18.1.1 Service1
Step 8 clear ssg host ip-address interface (Optional) Removes or disables a given host or subscriber.
Example:
Router# clear ssg host 192.168.1.1 fastethernet
Troubleshooting Initial SSG Communication

SUMMARY STEPS
1. debug radius
2. debug ssg port-map {events | packets}
DETAILED STEPS

Step 1 debug radius Displays debugging information associated with
RADIUS.
Example: • Use this command to troubleshoot
Router # debug radius communication between SSG and the AAA
server.
Step 2 debug ssg port-map {events | packets} Displays debug messages for port-mapping.
Example:
Router # debug ssg port-map events
Configuration Examples for Establishing Initial SSG

Communication
This section contains the following examples:
• SSG Interface Direction: Examples, page 36
• SSG Interface Redundancy: Examples, page 36
• SSG Port-Bundle Host-Key Configuration: Example, page 37
• SSG and AAA Server Interaction Configuration: Example, page 37
• Establishing Initial SSG Communication: Example, page 38

78-17497-01 35
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 cef
ssg enable
!
interface FastEthernet 1/0
ssg direction downlink
Setting 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 cef
ssg enable
!
interface ATM 1/0.1 point-to-point
range MyRange pvc 1/32 1/42
exit
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 cef
ssg enable
!
ssg bind service sample-service atm 1/0.1
ssg bind service sample-service atm 1/0.2 100
!
ip address 10.1.0.1 255.255.0.0
ssg direction uplink member groupA
!
ip address 10.2.0.1 255.255.0.0
!
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 cef
ssg enable
!
ssg bind service sample-serviceA 10.1.1.1

36 78-17497-01
!
interface ethernet 1/0
ip address 10.0.1.1 255.255.255.0
ssg direction uplink member service-groupA
!
ip address 10.0.2.1 255.255.255.0
!
ip route 10.1.1.1 255.255.255.255 eth 1/0 10
ip 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”).
ip cef
ssg enable
!
ssg bind service serviceB 10.0.0.1
ssg bind service serviceB 20.0.0.1
!
ip address 10.0.0.2 255.255.255.0
ssg direction uplink member groupB
!
ip address 20.0.0.2 255.255.255.0
ssg 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-map
destination range 8080 to 10100 ip 10.13.6.100
port-map destination access-list 100
port-map source ip Loopback1
SSG 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)

78-17497-01 37
!
aaa new-model
aaa authentication ppp default group radius
aaa authorization network default group radius
aaa authorization network ssg_aaa_author_internal_list none
aaa accounting network default start-stop group radius
!
! Enables CEF
ip cef
!
! Enables SSG
ssg enable
### Configures password for service-profile download
ssg service-password servicecisco
!
! Configures SSG communication with the RADIUS server

!
radius-server host 192.168.2.62 auth-port 1812 acct-port 1813 key cisco
radius-server key cisco
radius-server vsa send accounting
radius-server vsa send authentication
Establishing 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 server
aaa new-model
!
! Configures login access
aaa 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 radius
aaa authentication login console local
!
! Configures PPP authentication, service-profile authorization,
! l2tp tunnel authorization, accounting-list
aaa accounting network default start-stop group radius
!
aaa nas port extended
aaa session-id common
!
!
! Enables CEF
ip cef
!
! Enables SSG
ssg enable
! Configures the default network
ssg default-network 192.168.2.0 255.255.255.0
! Configures the shared key between SSG and the AAA server

38 78-17497-01
Where To Go Next
!
! Configures SSG-SESM API communication
ssg radius-helper auth-port 1812 acct-port 1813
ssg radius-helper key cisco
!
! Configures SSG port-bundle host-key
ssg port-map
source ip Loopback10
source ip Loopback11
!
! Configures an interface towards services (uplink interface)
interface FastEthernet1/0.1
description SSG-Service internet
encapsulation dot1Q 10
ip address 10.1.1.41 255.255.255.0
ip nat outside
ip nbar protocol-discovery
no ip mroute-cache
ssg direction uplink
!
! Configures an interface towards subscribers (downlink interface)
interface FastEthernet2/0.1
description Subscriber Access
encapsulation dot1Q 70
ip address 10.1.1.1 255.255.255.0
!
! Configures SSG communication with the RADIUS server
radius-server attribute 44 include-in-access-req
radius-server attribute 55 include-in-acct-req
radius-server attribute nas-port format d
radius-server retransmit 5
radius-server timeout 30
radius-server key cisco
!
Where To Go Next
• TBD

78-17497-01 39
The following sections provide references related to establishing SSG connectivity.
Related Documents
SSG commands Cisco IOS Service Selection Gateway Command Reference,
Release 12.4
SESM Cisco Subscriber Edge Services Manager documentation.
RADIUS configuration tasks Cisco IOS Security Configuration Guide, Release 12.4
MIBs
MIBs MIBs Link
The Service Selection Gateway MIB enables network To locate and download MIBs for selected platforms, Cisco IOS
administrators to use Simple Network Management releases, and feature sets, use Cisco MIB Locator found at the
Protocol (SNMP) to monitor and manage SSG. The following URL:
SSG MIB contains objects that correspond to and allow http://www.cisco.com/go/mibs
the monitoring of several important SSG features.
For detailed list of MIB objects and their definitions,
see the CISCO-SSG-MIB.
Description Link
even more content.
Feature Information for Implementing SSG

Table 6 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.
Not all commands may be available in your Cisco IOS software release. For details on when support for
a specific command was introduced, see the command reference documentation.

40 78-17497-01
For information on a feature in this technology that is not documented here, see the Service Selection
Gateway Features Roadmap.
Cisco IOS software images are specific to a Cisco IOS software release, a feature set, and a platform.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image
support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on
Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at
the login dialog box and follow the instructions that appear.
Table 6 Feature Information for Implementing SSG: Initial Tasks
Feature Name Releases Feature Configuration Information

Initial SSG Communication 12.0(3)DC The Initial SSG Communication feature comprises initial
12.3(4)B tasks you need to perform to enable SSG on the router and
12.2(11)T to establish SSG communication with other key
12.3T components of the network, including Subscriber Edge
12.4 Services Manager (SESM) and the authentication,
authorization, and accounting (AAA) server.
The following sections provide information about this
feature:
• Enabling SSG, page 18
• Configuring the Default Network, page 25
• Configuring SSG-SESM API Communication, page 26
SSG Direction Configuration for Interfaces and 12.2T SSG implements service selection through selective routing
Ranges 12.3(4)T 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:
• Configuring SSG Interface Direction, page 19
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.
feature:
• Uplink Interface Redundancy Overview, page 20
• Downlink Interface Redundancy Overview, page 20

78-17497-01 41
Table 6 Feature Information for Implementing SSG: Initial Tasks (continued)

SSG Port-Bundle Host-Key 12.3(4)B The SSG Port-Bundle Host Key feature enhances
12.2(11)T communication and functionality between the Service
12.3T Selection Gateway (SSG) and the Cisco Subscriber Edge
12.4 Services Manager (SESM) by introducing a mechanism that
uses the host source IP address and source port to identify
and monitor subscribers.
feature:
• Configuring SSG Port-Bundle Host-Key Functionality,
page 27
• Configuring SSG to AAA Server Interaction, page 33
SSG Unconfig 12.2T The SSG Unconfig feature releases and cleans up system
12.3(4)T resources acquired by SSG.
feature:
• System Resource Cleanup When SSG Is Unconfigured,
page 19
The following command was introduced by this feature: no
ssg enable force-cleanup.

42 78-17497-01
Configuring SSG to Serve as a RADIUS Proxy
The RADIUS proxy feature is principally an insertion mechanism to allow an SSG device to be
introduced to a network with minimum disruption to the existing network access server (NAS) and
authentication, authorization, and accounting (AAA) server(s). By acting as a proxy between a NAS
using RADIUS authentication (which may or may not be Cisco equipment) and a AAA server, SSG is
able to “sniff” the RADIUS flows and transparently create a corresponding SSG session, on successful
authentication of the subscriber. This provides an autologon facility with respect to SSG for subscribers
that are authenticated by devices that are closer to the network edge. This document describes the types
of deployments that use SSG as a RADIUS proxy and how to configure them.
Module History
This module first published May 2, 2005, and last updated May 2, 2005.

and configuration, use the “Feature Information for SSG RADIUS Proxy” section on page 77.
Contents
• Prerequisites for SSG RADIUS Proxy, page 43
• Restrictions for SSG RADIUS Proxy, page 44
• Information About SSG Authentication Using RADIUS Proxy, page 44
• How to Configure SSG RADIUS Proxy, page 46
• Configuration Examples for SSG Authentication of RADIUS Proxy Subscribers, page 71
• Feature Information for SSG RADIUS Proxy, page 77
Prerequisites for SSG RADIUS Proxy

Before you can perform the tasks in this process, you must enable SSG by completing the steps in the
task Enabling SSG in the “Implementing SSG: Initial Tasks” module.

78-17497-01 43
Restrictions for SSG RADIUS Proxy
Before you can configure SSG as a RADIUS proxy, you must first configure the RADIUS clients and
the RADIUS servers.
Restrictions for SSG RADIUS Proxy

• Loose coupling of host objects and client device contexts. Not all error conditions can be guaranteed
to be cleanly recovered without end-user intervention such as reconnecting.
• Scalability. If the number of contexts supported by a RADIUS-client device exceeds the maximum
number of host objects on a single SSG, external load balancing for a two-router solution is required.
Information About SSG Authentication Using RADIUS Proxy

This section describes the following concepts:
• SSG AutoLogon Using RADIUS Proxy, page 44
• RADIUS Server Redundancy, page 45
• Broadcast of Host Accounting, page 45
• RADIUS Client Subnet Definition, page 45
• Host Route Insertion, page 45
• Types of Deployments that Use SSG RADIUS Proxy, page 46
SSG AutoLogon Using RADIUS Proxy

The RADIUS proxy feature is principally an insertion mechanism to allow an SSG device to be
introduced to a network with minimum disruption to the existing NAS and AAA server(s). By acting as
a proxy between a client device using RADIUS authentication (which may or may not be Cisco
equipment) and a AAA server, SSG is able to "sniff" the RADIUS flows and transparently create a
corresponding SSG session, on successful authentication of the subscriber. This provides an
"autologon" facility with respect to SSG for subscribers that are authenticated by devices that are closer
to the network edge.
When configured as a RADIUS proxy, SSG transparently proxies all RADIUS requests generated by a
client device and all RADIUS responses generated by the corresponding AAA server, as described in
RFCs 2865, 2866 and 2869.
This RADIUS proxy functionality is largely agnostic to the type of client device, e.g. GGSN, PDSN,
WLAN AP etc. and supports standard authentication (i.e. a single Access-Request/Response exchange)
using both PAP and CHAP, Access-Challenge packets, and also EAP mechanisms (RFC 2869). Of the
various types of EAP authentication in existence (which differ, for example, in the transport mechanism
for the session keys), EAP-SIM and EAP-TLS are supported.
Where authentication and accounting requests originate from separate RADIUS client devices, SSG will
associate all requests to the appropriate session through the use of certain correlation rules. This may
occur for centralized PWLAN deployments, wherein authentication requests originate from the WLAN
AP while accounting requests are generated by the AZR. The association of the disparate RADIUS
flows to the underlying session is performed automatically where the combination of username (attribute

44 78-17497-01
Information About SSG Authentication Using RADIUS Proxy
1) and calling-station-id (attribute 31, if present) is sufficient to make the association reliable. However,
in some cases, configuration (i.e. the specification of additional attributes for use as correlation keys) is
required to coerce the correct association.
Following a successful authentication, authorization data gleaned from the RADIUS response is applied
to the corresponding SSG session.
Termination of a session created via RADIUS proxy operation is generally effected by receipt of an
Accounting-Stop packet with an appropriate session. Accounting-On/Off from a RADIUS client will
result in the termination of all SSG sessions hosted by that client.
RADIUS Server Redundancy

When SSG acts as a RADIUS Proxy for a client device (GGSN, PDSN, HA etc.), access-requests that
are generated by the client device are forwarded to the default RADIUS server, that is the first configured
server. If this server fails, SSG provides fail-over to the next configured server (if present).
Broadcast of Host Accounting

SSG RADIUS Proxy for GPRS networks can provide geographical redundancy by copying host object
accounting packets and sending them to multiple RADIUS servers.
RADIUS Client Subnet Definition

SSG will only proxy RADIUS packets originating from trusted client devices whose addresses have been
explicitly configured in SSG. If SSG is acting as a proxy for multiple client devices, each of which
resides on the same subnet, then the clients may be configured using a subnet definition rather than
discrete IP addresses for each device. This configuration method results in a single client configuration
entry for all the client devices, thus all client devices on this subnet must be configured with the same
shared secret. Furthermore all these devices must be of the same type. For example CDMA2000 PDSNs
and HAs (see …) must not share the same subnet configuration, although they may reside on the same
subnet.
Host Route Insertion

By default, SSG inserts a static route to the host for proxy users (if there is no existing route available).
For some installations, this may be either unnecessary or even undesirable, so you can disable the host
route insertion on a per-client basis.
Note The host-route insert command does not apply to Auto-domain users that are not RADIUS-Proxy users.
These users always have an IP address before any SSG involvement and so SSG would never be able to
insert a static route.
When a host object is created, SSG checks to see if the host is reachable (on the correct interface) by an
existing route and adds the static route only if it is not, and the insertion of host routes is enabled.

78-17497-01 45
How to Configure SSG RADIUS Proxy
For the case where insertion of host routes is disabled, an "unrouted" timer may also be defined. If
configured this timer is started when a host object is created with an unroutable IP address. If this IP
address does not become routable (e.g. due to a routing protocol update) before the timer expires , then
the host object is destroyed.
Types of Deployments that Use SSG RADIUS Proxy

SSG can be used as a RADIUS Proxy for subscriber authentication in the following types of
deployments:
• GPRS networks
• CDMA2000
• 802.1X WLAN

To configure SSG as a RADIUS proxy, use the tasks below. The first task applies to all RADIUS Proxy
deployments and you need to perform this task first. The next three tasks are specific to particular
deployments. The last two tasks apply to all RADIUS proxy deployments.
• Configuring SSG Autologon Using RADIUS Proxy, page 46 (required)
• Configuring SSG RADIUS Proxy for GPRS Networks, page 53 (optional)
• Configuring SSG RADIUS Proxy for CDMA2000 Deployments, page 55 (optional)
• Configuring SSG RADIUS Proxy for 802.1x WLAN Deployments, page 62 (optional)
• Monitoring and Maintaining SSG RADIUS Proxy, page 67 (optional)
• Troubleshooting SSG RADIUS Proxy, page 69 (optional)
Configuring SSG Autologon Using RADIUS Proxy

This feature allows SSG to as a proxy between a client device using RADIUS authentication and a AAA
server and by "sniffing" the RADIUS flows, transparently create a corresponding SSG session, on
successful authentication of the subscriber. Perform the following tasks to configure SSG Autologon
Using RADIUS Proxy:
• Enabling SSG Autologon Using RADIUS Proxy, page 46 (required)
• Configuring Session Identification Attributes, page 48 (optional)
• Configuring Timers for RADIUS Proxy, page 49(optional)
• Configuring Multiple RADIUS Server Support, page 51 (optional)
Enabling SSG Autologon Using RADIUS Proxy

Perform this task to enable SSG Autologon using RADIUS Proxy.

46 78-17497-01
SUMMARY STEPS
1. ssg radius-proxy
2. server-port [auth auth-port][acct acct-port]
3. client-address ip-address [mask] key secret
4. forward accounting-start-stop [server-group group-name]
5. no host-route insert
6. exit
DETAILED STEPS

Step 1 ssg radius-proxy Enables SSG RADIUS Proxy and enters
SSG-RADIUS-Proxy mode.
Example:
Router(config)# ssg radius-proxy
Step 2 server-port [auth auth-port][acct acct-port] Configures the authentication and accounting ports.
• auth—(Optional) Configures the authentication
Example: port.
Router(config-radius-proxy)# server-port auth 23
acct 45
• auth-port—(Optional) Specifies the
authentication port number. The default
authentication port is 1645. The valid range is 0
to 65535.
• acct—(Optional) Configures the accounting
port.
• acct-port—(Optional) Specifies the accounting
port number. The default accounting port is 1646.
The valid range is 0 to 65535.
Step 3 client-address ip-address [mask] key secret Configures the client IP address and the shared key
secret of a RADIUS client.
Example: • ip-address—IP address of a RADIUS client.
Router(config-radius-proxy)# client-address
172.16.0.0 key cisco
• mask—Configures the client IP address as a
subnet rather than as a discrete NAS IP address
• key—Shared secret with the RADIUS client.
• secret—Description of the shared secret.
Step 4 forward accounting-start-stop [server-group (Optional) Proxies accounting start/stop/update
group-name] packets generated by any RADIUS clients to the
AAA server.
Example:
Router(config-radius-proxy)# forward • server-group group-name—Configures SSG to
accounting-start-stop proxy RADIUS accounting packets to a specific
server group.

78-17497-01 47

Step 5 no host-route insert (Optional) Disables default host route insertion, on a
per-client basis.
Example:
Router(config-radproxy-client) no host-route insert
Step 6 end Returns to privileged EXEC mode.
Example:
Router(config-radius-proxy)# end
Configuring Session Identification Attributes

By default, SSG selects the attribute used for session identification based on the type of client device.
SSG assigns the 3GPP2-Correlation-ID attribute for PDSNs, Accounting-Session-ID attribute for HAs,
and Calling-Station-ID attribute for non-CDMA2000 devices. You can override this automatic selection
by using the following commands:
SUMMARY STEPS
1. ssg radius-proxy
2. client-address [ip-address]
3. key [secret]
4. session-identifier {auto | msid | correlation-id | accounting-session-id | ip | username}
5. remove vsa {3gpp2 | cisco}
DETAILED STEPS

Step 1 ssg radius-proxy Enables SSG RADIUS Proxy and enters SSG-RADIUS-Proxy
mode.
Example:
Step 2 client-address ip-address Configures the RADIUS-client to proxy requests from the
specified IP address to the RADIUS server and enters
SSG-RADIUS-Proxy-Client mode.
Example:
Router(config-radius-proxy)#
client-address 1.2.3.6
Step 3 key secret (Optional) Configures the shared secret between SSG and the
RADIUS client. The secret attribute describes the shared secret.
Example:
Router(config-radproxy-client)# key
mypassword

48 78-17497-01

Step 4 session-identifier {auto | msid | (Optional) Overrides SSG’s automatic RADIUS client session
correlation-id | accounting-session-id | identification.
ip | username}
• auto—Automatically determines the session identifier.
Example: • msid—Uses the MSID as the client session identifier.

Router(config-radproxy-client)# • correlation-id—Uses the Correlation-ID as the session
session-identifier auto
identifier.
• accounting-session-id—Uses the Accounting-Session-ID as
the session identifier.
• ip—Specifies the user IP address as the session identifier.
• username—Specifies the username as the session identifier.
Step 5 remove vsa {3gpp2 | cisco} (Optional) Removes a VSA for a RADIUS client.
• 3gpp2—Removes all 3GPP2 VSAs.
Example: • cisco—Removes all Cisco VSAs.
Router(config-radproxy-client)# remove
vsa 3gpp2
Router(config-radproxy-client)# remove
vsa cisco
Configuring Timers for RADIUS Proxy

During the lifetime of an SSG RADIUS Proxy session, SSG expects to receive certain external events
which are required for the session to continue. Whilst SSG is waiting for such external events, internal
timers are running. If these timers expire, the RADIUS Proxy session is terminated.
Perform this task to configure the SSG RADIUS Proxy timers.
SUMMARY STEPS
1. ssg proxy-radius
2. server-port [auth auth-port][acct acct-port]
3. timeouts
4. hand-off timeout
5. idle timeout
6. ip-address timeout
7. msid timeout retry retries

78-17497-01 49
DETAILED STEPS

Step 1 ssg proxy-radius Enables SSG RADIUS-Proxy and enters
SSG-RADIUS-Proxy mode.
Example:
Router(config)# ssg proxy-radius
Step 2 server-port [auth auth-port][acct acct-port] Configures the authentication and accounting ports.
• auth—(Optional) Configures the authentication port.
Example: • auth-port—(Optional) Specifies the authentication
Router(config-radius-proxy)# server-port
[auth 1645][acct 1646]
port number. The default authentication port is 1645.
The valid range is 0 to 65535.
• acct—(Optional) Configures the accounting port.
• acct-port—(Optional) Specifies the accounting port
number. The default accounting port is 1646. The valid
range is 0 to 65535.
Step 3 timeouts Enters SSG-RADIUS-Proxy-timeouts mode.
Example:
Router(config-radius-proxy)# timeouts
Step 4 hand-off timeout Configures the RADIUS Proxy hand off timeout. Valid
range is 1 to 30 seconds.
Example:
Router(config-radproxy-timer)# hand-off 30
Step 5 idle timeout [reset-mode {radius | mixed}] Configures a host object timeout value. Valid range is 30 to
65536 seconds.
Example: • reset-mode—Specifies the type of traffic that resets
Router(config-radproxy-timer)# idle 150 the idle timer.
• radius—Resets the timer exclusively by RADIUS
traffic
• mixed—Resets the timer by both data traffic and
RADIUS traffic.
• If the reset mode is not set, by default the idle timer
resets on receipt of data traffic.
Step 6 session timeout Configures the global session timeout for RADIUS proxy
sessions. Valid range is from 30 to 65535. There is no
default value.
Example:
Router(config-radproxy-timer)# session 100
Step 7 ip-address timeout Configures an SSG RADIUS Proxy IP address timeout.
Valid range is 1 to 30 seconds.
Example:
Router(config-radproxy-timer)# ip-address 25

50 78-17497-01

Step 8 msid timeout retry retries Configures the SSG RADIUS Proxy mobile station ID
(MSID) timeout. Valid range is 1 to 5 seconds.
Example: • timeout—Timeout value, in seconds. Valid range is 1
Router(config-radproxy-timer)# msid 4 retry 9 to 5 seconds. The default is 1 second.
• retry retries—Specifies the maximum number of
times the MSID timer is restarted before SSG assumes
it is not going to receive an MSID from the PDSN.
Valid range is 1 to 20 retries. The default is 10 retries.
Step 9 unrouted timeout Configures the RADIUS proxy unroutable IP address
timeout. Valid range is from 1 to 43200 seconds.
Example: • This timer may be used when insertion of host routes
Router(config-radproxy-timer)# unrouted 600 is disabled. If the IP address does not become routable
before the timer expires, the host object is destroyed.
Configuring Multiple RADIUS Server Support

Perform this task to configure geographical redundancy for accounting records by allowing copies of
host object accounting packets to be sent to multiple RADIUS servers. Note this is distinct from
RADIUS server failover - the requirement here is that clones of accounting packets are always forwarded
to each of the configured servers, not just when the primary server fails. To configure the support for
multiple RADIUS servers, use the following commands:
SUMMARY STEPS
1. aaa group server radius group-name

2. server ip-address [auth auth-port][acct acct-port]
3. Repeat Step 2 to configure additional RADIUS servers.
4. exit
6. server ip-address [auth auth-port][acct acct-port]
7. Repeat Step 6 to configure additional RADIUS servers.
8. exit
9. aaa accounting network ssg_broadcast_accounting start-stop broadcast group group-name 1
group group-name 2

78-17497-01 51
DETAILED STEPS

Step 1 aaa group server radius group-name Groups RADIUS server hosts into distinct lists and distinct
methods.
Example: • group-name—Character string used to name the group of
Router(config)# aaa group server radius servers.
myservergroup1
Step 2 server ip-address Configures the IP address of the RADIUS server for the group
[auth auth-port][acct acct-port] server.
• ip-address—IP address of the RADIUS server host.
Example:
Router(config-sg-radius)# server 1.2.3.4
• auth auth-port—(Optional) Specifies the User Datagram
[auth 1645][acct 1646] Protocol (UDP) destination port for authentication requests.
The [auth-port] argument specifies the port number for
authentication requests. The host is not used for
authentication if this value is set to 0.
• acct acct-port—(Optional) Specifies the UDP destination
port for accounting requests. The [acct-port] argument
specifies the port number for accounting requests. The host is
not used for accounting services if this value is set to 0.
Step 3 Repeat Step 2 to configure additional RADIUS servers.
Step 4 exit Exits server group RADIUS configuration mode.
Example:
Router(config-sg-radius)# exit
Step 5 aaa group server radius group-name Configures the second, redundant RADIUS server.
Example:
Router(config)# aaa group server radius
myservergroup2
Step 6 server ip-address Configures the IP address of the second RADIUS server for the
[auth auth-port][acct acct-port] group server.
Example:
Router(config-sg-radius)# server 1.2.3.5
[auth 1645][acct 1646]
Step 7 Repeat Step 6 to configure additional RADIUS servers.

52 78-17497-01

Step 8 exit Exits server group RADIUS configuration mode.
Example:
Router(config-sg-radius)# exit
Step 9 aaa accounting network Enables AAA accounting of requested services for billing or
ssg_broadcast_accounting start-stop security purposes when you use RADIUS.
broadcast group group-name group
group-name • ssg_broadcast_accounting—Configures the broadcast
group.
Example: • start-stop—Sends a “start” accounting notice at the
Router(config)# aaa accounting network beginning of a process and a “stop” accounting notice at the
ssg_broadcast_accounting start-stop end of a process. The “start” accounting record is sent in the
broadcast group myservergroup1 group background. The requested user process begins regardless of
myservergroup2
whether the “start” accounting notice was received by the
accounting server.
• broadcast—Enables sending accounting records to multiple
AAA servers. Simultaneously sends accounting records to
the first server in each group. If the first server is unavailable,
failover occurs using the backup servers defined within that
group.
• group group-name—Uses a subset of RADIUS servers for
accounting as defined by the server group group-name
command.
Configuring SSG RADIUS Proxy for GPRS Networks

The General Packet Radio System (GPRS) is a service that provides packet radio access for mobile
Global System for Mobile Communications (GSM) and time-division multiple access (TDMA) users.
By configuring SSG as a RADIUS proxy to the GGSN, SSG can provide service selection to and direct
traffic of mobile wireless subscribers.
Before you configure SSG RADIUS proxy support for GPRS networks, you should understand the
following concepts:
• Prerequisites, page 53
• Overview of SSG RADIUS Proxy in GPRS Networks, page 54
• IP Addresses Assignment in GPRS Networks that Use SSG RADIUS Proxy, page 54
• Support For Overlapped Host IP Addresses, page 54
• Forwarding of Accounting Packets, page 55
• Session Identification by IP address, page 55
• Per-PDP Accounting in GPRS Networks that Use SSG RADIUS Proxy, page 55
Prerequisites
Before you configure RADIUS Proxy in GPRS networks, you must complete the steps in Enabling SSG
Autologon Using RADIUS Proxy, page 46.

78-17497-01 53
Overview of SSG RADIUS Proxy in GPRS Networks

The General Packet Radio System (GPRS) is a service that provides packet radio access for Global
System for Mobile Communications (GSM) and time-division multiple access (TDMA) users.
The SSG RADIUS Proxy for GPRS feature allows an SSG device to be inserted between a GGSN and a
NAP AAA server and act as a proxy for the authentication and accounting RADIUS flows. By
monitoring these flows SSG can transparently create a corresponding SSG session, on successful
authentication of the subscriber, and thus provide the user with access to the full range of SSG features.
IP Addresses Assignment in GPRS Networks that Use SSG RADIUS Proxy

You can assign an IP address to the host object in any of the following ways; these are in order of
precedence (but not necessarily preference):
1. Use the IP specified in the Access-Request. In this case, the GGSN has assigned the IP address and
merely signals to the SSG the IP address that was allocated. SSG accepts this IP address (unless it
is replaced by an AAA assigned IP address as explained below) and the Access-Accept packet
replies with the same IP address.
2. Use the IP specified in the Access-Accept from the AAA. This is the case where the AAA server is
being used to manage IP addresses.
3. For Auto-domain cases, use the IP address returned from the service domain. For the case where an
IP address has not been assigned via the Access-Request or Access-Accept, the IP address from a
tunnel or proxy service may be used.
4. If an IP address has not been acquired by any other method, assign one from an ip local pool
configured for this purpose.
5. If an IP address was not assigned during the authentication phase, and no suitable local IP pools
were available for IP assignment then use the IP address in the Accounting-Start from the client
device. This is the case where the client device is using DHCP to allocate IP addresses.
If SSG receives an IP address in an AR from the GGSN, SSG proxies it to the AAA server. If the AAA
server returns a different address in the AA, SSG assigns it to the host object, and returns it to the GGSN
in the proxied AA. This in accordance with the RADIUS specification whereby IP addresses in ARs are
treated by the server as hints and do not have to be honored.
For the case of auto-domain tunnel or proxy services, if there is already an IP address, SSG assigns this
address to the host object and performs NAT towards this service.
If there is no existing route to the assigned IP address, static routes are added to the SSG's routing table
with RADIUS-client as next-hop. This default behavior may be overridden by configuration (see ….) if,
for example, routing protocols are in effect on the network and the the static route addition is
unnecessary.
Support For Overlapped Host IP Addresses

Overlapped host IP addresses are supported for hosts connected to SSG on different point-to-point (other
than RBE) downlink interfaces.

54 78-17497-01
Forwarding of Accounting Packets

While SSG is acting as a RADIUS Proxy for the GGSN it also receives all the Accounting packets. The
Accounting Stop packet is used as an indication of session termination. By default, only
Accounting-On/Off packets are forwarded to the real AAA server: Accounting-/Start/Stop/Update
packets are not forwarded and SSG generates the responses locally. A CLI is provided to override this
default behavior and allows transparent proxying of all accounting packets.
SSG will always proxy Accounting-On (or Accounting-Off) packets received from client GGSNs. These
are used to signal that the client GGSN has just rebooted (or is about to be rebooted). When SSG receives
the packets, SSG destroys all host objects associated with the specified client GGSN before forwarding
the packet. Note that SSG uses the NAS-IP-Address in the Accounting-On/Off packets to determine the
affected GGSN. This allows scenarios where multiple tunnel interfaces exist between the GGSN and
SSG. In these scenarios, although there are multiple RADIUS clients configured at SSG, only a single
Accounting-On/Off packet is generated by the GGSN. As part of normal SSG functionality, SSG sends
Accounting-Start/Update/Stop records for both the active host objects and for any services they are
connected to.
Session Identification by IP address

The default session identification is the MSID. To override this default and specify the subscriber’s IP
address as the session identifier, use the session-identifier command.
Per-PDP Accounting in GPRS Networks that Use SSG RADIUS Proxy

The Cisco GGSN (and presumably other GGSNs) supports per-PDP accounting rather than per-user
accounting. In this mode Accounting-Start/Stop packets are generated for each PDP context activated by
a subscriber, rather than a single pair representing the lifetime of the entire subscriber session. These
multiple Accounting-Start/Stop pairs share the same Framed-IP-Address attribute (that is, the IP address
of the user) and are distinguished by unique Accounting-Session-ID attributes..
SSG monitors the number of separate contexts associated with an IP address by monitoring the number
of (different) Accounting-Starts received. When the number of contexts drops to zero or SSG receives
an Accounting-Stop with a 3GPP-Session-Stop-Indicator, SSG terminates the session.
Configuring SSG RADIUS Proxy for CDMA2000 Deployments

This section describes how to configure SSG RADIUS Proxy for CDMA2000 deployments. Before you
configure SSG RADIUS proxy for CDMA2000 deployments, you should understand the following
concepts:
• CDMA, page 57
• SSG RADIUS Proxy for CDMA2000 Overview, page 57
• SSG RADIUS Proxy for CDMA2000 for Simple IP, page 58
• SSG RADIUS Proxy for CDMA2000 for Mobile IP, page 59
• Dynamic Home Agent Assignment, page 59
• Benefits of SSG RADIUS Proxy for CDMA2000, page 60

78-17497-01 55
This section contains the following tasks:

• Configuring Home Agent IP Addresses, page 60
• Verifying SSG RADIUS Proxy for CDMA2000, page 61
Prerequisites
PDSN
• All RADIUS packets (including Access-Request packets for the Cisco variant of Module Subscriber
Identity (MSID) based access) generated by the PDSN must contain the 3GPP2-Correlation-ID
VSA.
• Access-Request packets for the Cisco variant of MSID-based access generated by the PDSN must
contain the 3GPP2-Correlation-ID Vendor Specific Attribute (VSA).
• Accounting-Start packets generated by the PDSN must contain the 3GPP2-IP-Technology VSA.
HA
• No RADIUS packets generated by the HA can contain the 3GPP2-Correlation-ID VSA.
Note The following HA prerequisites are not standard HA behavior and must be configured.
• The HA must issue Access-Requests for all Mobile IP sessions.

• The HA must issue Accounting-Start packets and Accounting-Stop packets for all Mobile IP
sessions.
• The HA must provide the Acct-Session-ID attribute in all RADIUS packets it generates. This
enables the system to differentiate between multiple sessions with the same Network Access
Identifier (NAI).
Miscellaneous
• RADIUS Access-Accept packets sent by the RADIUS server must contain the
3GPP2-IP-Technology VSA.
Restrictions
SSG RADIUS Proxy for CDMA2000 requires non standard extensions to the Home Agent behavior. See
Prerequisites, page 56 for more information.
In Auto-domain mode, SSG bypasses user authentication at the Network Attached Storage (NAS)
Authentication, Authorization and Accounting (AAA) server. SSG instead downloads a generic profile
for the specified Auto-domain. This profile may be a service profile for simple Auto-domain or a virtual
user profile in extended mode Auto-domain. When SSG is acting as a RADIUS Proxy in a CDMA2000
network, the profile returned in an Access-Accept from the AAA server must contain the
3GPP2-IP-Technology VSA to indicate to SSG whether this call setup is for a Simple IP call or for a
Mobile IP call. Even if a network supports only one type of user (either all Simple IP users or all Mobile
IP users), the Access-Accept packets received from the AAA must contain the 3GPP2-IP-Technology
VSA. In networks that support only one type of user, the Auto-domain profiles can be formatted to
contain the correct attribute. In networks that support both Mobile IP and Simple IP users
simultaneously, the Access-Accept packets must contain the correct attribute for the type of user. The
AAA server must be able to modify the contents of the generic Auto-domain profile so that it contains

56 78-17497-01
the correct VSA. SSG must receive a real rather than a cached response from the AAA server for each
user logon. SSG Service Profile Caching must be disabled when SSG Auto-domain is enabled and SSG
is acting as a RADIUS Proxy in a CDMA2000 network that supports both Simple IP and Mobile IP users.
CDMA
Code Division Multiple Access (CDMA) is a digital spread-spectrum modulation technique used mainly
with personal communications devices such as mobile phones. CDMA digitizes the conversation and
tags it with a special frequency code. The data is then scattered across the frequency band in a
pseudorandom pattern. The receiving device is instructed to decipher only the data corresponding to a
particular code to reconstruct the signal.
For more information about CDMA, see the “CDMA Overview” knowledge byte on the Mobile Wireless
Knowledge Bytes web page:
http://www.cisco.com/warp/public/779/servpro/solutions/wireless_mobile/training.html.
CDMA2000 Radio Transmission Technology (RTT) is a wideband, spread-spectrum radio interface that
uses CDMA technology to satisfy the needs of third generation (3G) wireless communication systems.
CDMA2000 is backward compatible with CDMA.
For more information about CDMA2000, refer to the “CDMA2000 Overview” knowledge byte on the
Mobile Wireless Knowledge Bytes web page:
http://www.cisco.com/warp/public/779/servpro/solutions/wireless_mobile/training.html
SSG RADIUS Proxy for CDMA2000 Overview

The SSG RADIUS Proxy for CDMA2000 feature allows you to extend the functionality of the existing
SSG RADIUS Proxy so that it may be used in CDMA2000 networks.
Code Division Multiple Access (CDMA) is a digital spread-spectrum modulation technique used mainly
with personal communications devices such as mobile phones. CDMA digitizes the conversation and
tags it with a special frequency code. The data is then scattered across the frequency band in a
pseudorandom pattern. The receiving device is instructed to decipher only the data corresponding to a
particular code to reconstruct the signal.
When used in a CDMA2000 network, the Service Selection Gateway (SSG) provides RADIUS Proxy
services to the Packet Data Serving Node (PDSN) and the Home Agent (HA) for both Simple IP and
Mobile IP authentication. SSG also provides service selection management and policy-based traffic
direction for subscribers.
SSG RADIUS Proxy for CDMA2000, used with Cisco Subscriber Edge Services Manager (SESM),
provides users with on-demand services and service providers with service management and subscriber
management.
SSG RADIUS Proxy for CDMA2000 supports time- and volume-based usage accounting for Simple IP
and Mobile IP sessions. Prepaid and postpaid services are supported. Host accounting records can be
sent to multiple network elements, including Content Service Gateways (CSGs), Content Optimization
Engines (COEs), and Wireless Application Protocol (WAP) gateways.

78-17497-01 57
Figure 7 CDMA Network
AAA
Corporate
VPN
IP core
ISP
Access SSG
network WAP/Content
PDSN/FA gateway
Mobile BSC,
station BTS PCF
HA
75773
Radio Access Network (RAN)
Key to Figure 7
Item Description
BTS Base Transceiver Station
BSC Base Station Controller
PCF Packet Control Function
PDSN/FA Packet Data Serving Node / Foreign Agent
VPN Virtual Private Network
SSG RADIUS Proxy for CDMA2000 for Simple IP

When used in a CDMA2000 environment, SSG acts as a RADIUS Proxy to the Packet Data Serving
Node (PDSN) and to the Home Agent for Simple IP authentication. SSG sets up a host object for the
following three access modes:
• PAP/CHAP authentication. In this mode, Password Authentication Protocol/ Challenge Handshake
Authentication Protocol (PAP/CHAP) is performed during PPP setup and the NAI is received from
a mobile node (MN).
• MSID-based access. In this mode, the MN does not negotiate CHAP or PAP and no Network Access
Identifier (NAI) is received by the PDSN. The PDSN does not perform additional authentication.
PDSN constructs an NAI based on the MSID and generates accounting records. Because a user
password is not available from the MN, a globally configured password is used as the service
password.
• MSID-based access Cisco variant. In this mode, a Cisco PDSN supports MSID-based access by
using a realm retrieved from the RADIUS server. This realm is retrieved during an extra
authentication phase with the RADIUS server.
SSG operating in a CDMA2000 network correlates Accounting-Start and Accounting-Stop requests. A
PDSN may send out many Accounting-Start and Accounting-Stop requests during a session. These
Accounting-Start and Accounting-Stop requests can be generated by PDSN hand off, Packet Control
Function (PCF) hand off, interim accounting, and time-of-date accounting. SSG terminates a session

58 78-17497-01
only when it receives an Accounting-Stop request with the 3GPP2-Session-Continue VSA set to
“FALSE” or when a subsequent Accounting-Start request is not received within a configured timeout.
PPP renegotiation during a PDSN hand off is treated as a new session.
In SSG RADIUS Proxy for CDMA2000 for Simple IP, the end-user IP address may be assigned statically
by the PDSN, RADIUS server, or SSG. The end-user IP address can also be assigned directly from the
Auto-domain service.
Network Address Translation (NAT) is automatically performed when necessary. NAT is generally
necessary when IP address assignment is performed by any mechanism other than directly from the
Auto-domain service (which may be a VPN). You can also configure SSG to always use NAT.
If the user profile contains Cisco attribute-value (AV) pairs of Virtual Private Dialup Network (VPDN)
attributes, SSG initiates Layer 2 Tunneling Protocol (L2TP) VPN.
SSG RADIUS Proxy for CDMA2000 for Mobile IP

For Mobile IP, SSG functions as the RADIUS Proxy for both PDSN and the HA. SSG proxies PPP PAP
or CHAP and Mobile Node (MN)/Foreign Agent (FA) CHAP authentication. SSG RADIUS Proxy for
CDMA2000 for Mobile IP can assign IP addresses statically by the PDSN, RADIUS server, or SSG. The
end user IP address can also be assigned directly from the Auto-domain service.
Home Agent-Mobile Node (HA-MN) authentication and reverse tunneling must be enabled so that SSG
can create host objects for Mobile IP sessions based on proxied RADIUS packets received from the HA.
The Home Agent must generate RADIUS accounting packets so that SSG can discover the user IP
address and detect the termination of the session. Multiple Mobile IP sessions with the same NAI are
supported. RADIUS packets must contain the Accounting-Session-ID attribute to be associated with the
correct user session. SSG correlates RADIUS packets from the PDSN in order to obtain MSID
information for a host object of a Mobile IP session.
SSG can set up a host object either with or without PAP/CHAP performed during the original PPP
session.
SSG initiates L2TP VPN according to the SSG tunnel service VSAs in the user’s profile. If the user
profile contains Cisco AV pairs of VPDN, SSG sets up the L2TP tunnel per these VPDN attributes. SSG
removes these AV pairs when sending the Access-Accept packet back to the PDSN.
Either the HA or the RADIUS server can assign the user’s IP address.
Dynamic Home Agent Assignment

Dynamic HA assignment based on a mobile user’s location is supported.
The SSG RADIUS Proxy for CDMA2000 feature provides three options for dynamic HA assignment:
• The RADIUS server selects the local HA or any HA that is configured for session requests. For
foreign-user call requests, the AAA server assigns the HA.
• SSG modifies the fixed HA address received from the RADIUS server to a local HA address. This
method can be implemented without making any changes to the RADIUS server configuration. SSG
does not modify the HA address for a foreign user. The foreign-user call request is registered with
the HA address assigned by the AAA server.
• The PDSN implements dynamic HA assignment based on detection of the PDSN hand off.

78-17497-01 59
Benefits of SSG RADIUS Proxy for CDMA2000

SSG RADIUS Proxy for CDMA2000 provides the following features and capabilities:
• Centralized L2TP VPN tunnel management for Simple IP and for Mobile IP
• Centralized management for user service access and user-specific routing
– Automatic logon of a user to SSG when the user establishes a PPP session with the PDSN or a
Mobile IP flow with the HA
– Automatic logon of the user to a service based on the domain name, structured username
(user@domain), and Mobile Station ID (MSID). This eliminates the need for a service provider
to have to make changes to existing AAA servers for VPDN service.
• Dynamic HA assignment
• Multiservice networking, including simultaneous services and sequential services, without the user
having to log off and log back in
• Packet filtering. SSG uses Cisco IOS access control lists (ACLs) to prevent users, services, and pass
through traffic from accessing specific IP addresses and ports.
• Per-service and per-destination accounting and billing
• Prepaid for CDMA2000 services
• SSG TCP Redirect for Services to captive portals for unauthenticated users
Configuring Home Agent IP Addresses

SSG supports dynamic assignment of the Home Agent IP address using these commands. The HA IP
address will only be dynamically assigned for sessions from a domain configured using these commands,
where the domain is derived from the structured username of the session. The actual HA IP address
assigned may be configured globally (i.e. the same for all recognized domains) or on a per-domain basis.
To configure Home Agent domain names and Home Agent IP addresses, use the following commands:
SUMMARY STEPS
1. ssg proxy-radius
2. home-agent address [ip-address]
3. home-agent domain [domain-name] address [ip-address]
DETAILED STEPS

Step 1 ssg proxy-radius Enables SSG RADIUS Proxy and enters SSG-RADIUS-Proxy
mode.
Example:
Router(config)# ssg proxy-radius

60 78-17497-01

Step 2 home-agent address ip-address Configures an IP address for a Home Agent in a CDMA2000
network.
Example:
Router(config-radius-proxy)# home-agent
address 1.2.3.7
Step 3 home-agent domain domain-name [address Configures a domain for a Home Agent in a CDMA2000 network.
ip-address] Optionally configures an IP address for the domain.
Example:
Router(config-radius-proxy)# home-agent
domain mydomain.com address 1.2.3.8
Verifying SSG RADIUS Proxy for CDMA2000

Perform this task to verify SSG RADIUS Proxy for CDMA2000.
SUMMARY STEPS
1. show ssg host [ip-address]
DETAILED STEPS
Step 1 show ssg host [ip-address]

Use the show ssg host command to display information about a host object including client device type.
The following example shows host object information for Simple IP:
------------------------ HostObject Content -----------------------

Activated: TRUE
Interface:
User Name: user1
Host IP: 10.0.0.0
Msg IP: 0.0.0.0 (0)
Host DNS IP: 0.0.0.0
Proxy logon from client IP: 10.0.48.3
Device: PDSN (Simple IP)
NASIP : 10.0.48.3
SessID: 12345678
APN :
MSID : 5551000
Timer : None
Maximum Session Timeout: 0 seconds
Host Idle Timeout: 60000 seconds
Class Attr: NONE
User policing disabled
User logged on since: *05:59:46.000 UTC Fri May 3 2002
User last activity at: *05:59:52.000 UTC Fri May 3 2002
SMTP Forwarding: NO
Initial TCP captivate: NO
TCP Advertisement captivate: NO
Default Service: NONE
DNS Default Service: NONE
Active Services: internet-blue;
AutoService: internet-blue;

78-17497-01 61
Subscribed Services: internet-blue; iptv; games; distlearn; corporate; shop; banking;

vidconf;
Subscribed Service Groups: NONE
The following example shows host object information for Mobile IP:

Activated: TRUE
Interface:
User Name: user1
Host IP: 10.0.0.101
Msg IP: 0.0.0.0 (0)
Proxy logon from client IP: 10.0.48.4
Device: HA
NASIP : 10.0.48.4
SessID: 44444445
APN :
MSID : 5551001
Timer : None
Class Attr: NONE
SMTP Forwarding: NO
Active Services: internet-blue;
AutoService: internet-blue;
Subscribed Services: internet-blue; iptv; games; distlearn; corporate; shop; banking;
vidconf;
Configuring SSG RADIUS Proxy for 802.1x WLAN Deployments

In 802.1x WLAN deployments, SSG acts as a RADIUS Proxy during Extensible Authentication Protocol
(EAP) authentication between a WLAN AP and the corresponding AAA server. Using SSG as a
RADIUS Proxy in 802.1x deployments enables WLAN users to access SSG functionality after they have
connected to the AP.
Before you configure SSG RADIUS Proxy for 802.1x WLAN deployments, you should understand the
following concepts:
• EAP Implementations Supported by SSG, page 63
• SSG EAP Environment, page 63
• EAP Transparency, page 64
• Prevention of IP Address Reuse, page 65
• User Reconnect After Logoff, page 65
Perform the following task to configure SSG RADIUS Proxy for 802.1x WLAN deployments:
• Configuring SSG RADIUS Proxy for 802.1x Deployments, page 65

62 78-17497-01
Prerequisites
The SSG EAP Transparency features operates in the environment described in the “SSG EAP
Environment” section on page 63. Before you can use this feature, you must set up each of the
components of the environment, as specified in other Cisco documents.
The SSG EAP Transparency feature has the following requirements:
• You must set up the SSG RADIUS Proxy feature on the router that has SSG. It enables the SSG to
be aware of EAP authentication and process the user’s SSG service information sent in the
Access-Accept packet. You also must configure the access point (AP) and AZR as the RADIUS
Proxy client.
• The AP must use SSG as the authentication, authorization, and accounting (AAA) server for EAP
authentication.
• The AZR must use the Domain Host Configuration Protocol (DHCP) accounting feature and the
Address Resolution Protocol (ARP) log feature.
• SESM must be in RADIUS mode.
EAP Implementations Supported by SSG

SSG supports the following EAP implementations, which are designed to support 802.1x requirements
for public wireless LANs (PWLANs) and Ethernet LANs:
• EAP-Subscriber Identity Module (SIM)
• EAP-Transport Layer Security (TLS)
• Microsoft Protected Extensible Authentication Protocol (PEAP)
• Any other EAP mechanisms that use Microsoft Point-to-Point Encryption (MPPE) to share Wired
Equivalent Privacy (WEP) keys
Note SSG does not terminate native EAP messages. SSG supports EAP transparency by looking at the
RADIUS packets generated by APs or switches.
SSG EAP Environment

EAP authentication is an enhancement to Global System for Mobile communications (GSM)
authentication and operates over the IEEE 802.1x standard. The Cisco implementation of EAP
transparency for PWLANs operates in conjunction with the following components:
• Wireless LAN (WLAN) Access Point (AP)— A Network Access Server (NAS) to which wireless
device users connect to this to reach the network. APs have radio channels on the user side and IP
infrastructure on the network side.
• Access Zone Router (AZR)—A router that represents a “hotspot,” or access zone, and serves
multiple clients in a populated area, such as an airport or coffee shop. Multiple Access Points are
served by one AZR. The AZR is also the DHCP server for clients. The AZR is generally a lower-end
Cisco router such as a Cisco 1700 or Cisco 2600-XM series routers.
• Cisco Service Selection Gateway (SSG)—A Cisco IOS feature that implements Layer 3 service
selection through selective routing of IP packets to destination networks on a per-subscriber basis.
When configured as a RADIUS Proxy between a WLAN AP and the corresponding AAA server,
SSG enables users to access SSG functionality after they connect to the AP.

78-17497-01 63
• Subscriber Edge Services Manager (SESM)—An extensible set of applications for providing
support for on-demand value-added services and access control at the network edge. Together with
SSG, SESM provides subscriber authentication, service selection, and service connection
capabilities to subscribers of Internet services. Subscribers interact with an SESM web application
and portal using a standard Internet browser. In RADIUS mode, SESM obtains subscriber and
service information from a RADIUS server. (SESM in RADIUS mode is similar to the Cisco Service
Selection Dashboard (SSD), which was replaced by SESM.)
• Authentication, authorization, and accounting (AAA) server—This server validates the claimed
identity of a user device, grants access rights to a user or group, records who performed a certain
action, and tracks user connections and certain activities, such as service and network resource
usage. An AAA database is managed and accessed by a RADIUS security server.
• RADIUS server—An access server that uses the AAA protocol. It is a system of distributed security
that secures remote access to networks and network services against unauthorized access. The server
runs on a central computer, typically at the customer’s site, and the clients reside in the dialup access
servers and can be distributed throughout the network.
• Signaling System 7 (SS7) network—A system that stores information that is required for setting up
and managing telephone calls on the public switched telephone network (PSTN). The information
is stored on a network separate from the network on which the call was made. The AAA server
communicates with a Cisco IP Transfer Point (ITP), which acts as a gateway between the IP and SS7
networks. Using Mobile Application Part (MAP) messages, the system gets user service profiles
from the subscriber’s Home Location Register (HLR). In addition, the system includes an
authentication center (AuC), which provides authentication and encryption parameters to verify
each user’s identity and ensure call confidentiality.
On the client side, the EAP protocol is implemented in the EAP supplicant. The supplicant code is linked
into the EAP framework provided by the operating system; currently, supplicants exist for Microsoft
Windows XP and Windows 2000. The EAP framework handles EAP protocol messages and
communications between the supplicant and the AAA server; it also installs any encryption keys
provided to the supplicant in the client’s WLAN radio card.
On the network side, the EAP authenticator code resides on the service provider’s AAA server. Besides
handling the server side of the EAP protocol, this code is also responsible for communicating with the
service provider’s AuC. In a Cisco implementation of EAP, the AAA server communicates with a Cisco
IP transfer point (ITP). The Cisco ITP translates messages from the AAA server into standard GSM
protocol messages, which are then sent to the AuC.
EAP Transparency
The SSG EAP Transparency feature allows SSG on a Cisco router to act as a RADIUS Proxy during EAP
authentication. SSG creates the host after successful EAP authentication, so the user does not have to
log on through the web portal. Instead, the user is automatically logged in.
The AP does the authentication for the client. SSG looks like a AAA server, which proxies relevant
packets to the real AAA server. To create a host automatically, SSG has to know that the authentication
was successful. By proxying messages, it obtains this information. The IP address is not assigned until
authentication is complete, so SSG creates an inactive host and uses the MAC address as an identifier.
To get the IP address, it waits for a DHCP Accounting Start from the AZR, so the AZR must be
configured as an SSG RADIUS Proxy client.

64 78-17497-01
Prevention of IP Address Reuse

When the AZR reboots, it sends Accounting On/Off packets. SSG receives these packets and, even
though EAP users may be connected, it moves hosts to the inactive state and starts an inactive-period
timer. During the DHCP renewal, the AZR performs an ARP lock and sends an Accounting Start packet
to SSG. After receiving an Accounting Start packet, SSG activates the corresponding hosts using the
MAC address as the identity. If the inactive-period timer expires, SSG removes all of the inactive hosts.
This functionality prevents the use of previously valid IP addresses after an AZR reboot. It closes a
security hole that could allow an illegal user to hijack the session of a valid user through the IP address,
and at the same time it removes the inconvenience of reauthentication for the user. In order to prevent
the reuse of IP addresses, clients must be configured with a short DHCP lease interval. If users are not
configured with a short lease interval, they will have to reauthenticate whenever the AZR reboots.
User Reconnect After Logoff

EAP users do not have a username and password as other types of SSG users do. If they access SESM,
log off, and try to reconnect to the service later, SESM presents them with a logon page, which they
cannot use. To allow EAP users to reconnect without being asked to log on again, enable the user
reconnect functionality with the ssg wlan reconnect command.
The following steps describe the SSG EAP transparency user reconnect process:
1. The user connects to SSG via an EAP mechanism, and SSG creates the host (as explained in the
“EAP Transparency” section).
2. The user accesses SESM. SESM queries SSG about the user, and SSG provides SESM with the user
profile information. SESM displays the service logon page for the user to select services.
3. When the EAP user logs off SESM, SSG does not remove the host (as it does for other types of
users), but rather inactivates the host.
4. The user attempts to access SESM again to use a service. SESM queries SSG. SSG activates the host
and enables autologon services.
SSG deletes an active or inactive host when it receives an Accounting Stop packet from the AZR.
The SSG EAP transparency user reconnect functionality can be enabled or disabled using the
command-line interface, as described in the “SUMMARY STEPS” section on page 65.
Note If user reconnect is enabled and a user refreshes or reloads the SESM page after an account logoff, SESM
sends a query to SSG, which causes SSG to activate the host. It is recommended that users be made aware
of this behavior so they do not accidentally activate the host.
Configuring SSG RADIUS Proxy for 802.1x Deployments

Perform this task to configure SSG as a RADIUS proxy in a 802.1x WLAN deployment.
SUMMARY STEPS
1. ssg radius-proxy
2. client-address IP-address
3. key secret
4. session-identifier {auto | msid | correlation-id | accounting-session-id}

78-17497-01 65
5. timeouts
6. idle timeout
or
ip-address timeout
7. exit
8. exit
9. Repeat Steps 5 to 9 to configure the AZR as a RADIUS client.
10. ssg wlan reconnect
DETAILED STEPS

Step 1 ssg radius-proxy Enables SSG RADIUS Proxy and SSG-RADIUS-Proxy
configuration mode.
Example:
Step 2 client-address IP-address Configures the RADIUS client IP address.
• Use this command to configure the AP as a RADIUS
Example: client to proxy requests from the specified IP address to
Router(config-radius-proxy)# client-address the RADIUS server.
123.123.123.123
Step 3 key secret Configures the shared secret.
• Use the secret argument to configure each client IP with a
Example: unique shared secret. This shared secret should be the
Router(config-radproxy-client)# key cisco same one that is configured on the RADIUS client.
Step 4 session-identifier {auto | msid | (Optional) Overrides SSG automatic RADIUS client
correlation-id | accounting-session-id} session identification. Keywords are as follows:
• auto—Automatically determines the session identifier.
Example:
Router(config-radproxy-client)#
• msid—Uses the MSID as the client session identifier.
session-identifier auto • correlation-id—Uses the Correlation-ID as the session
identifier.
• accounting-session-id—Uses the
Accounting-Session-ID as a session identifier.
Step 5 timeouts (Optional) Enters SSG-RADIUS-Proxy-Timeouts mode.
Example:
Router(config-radproxy-client)# timeouts

66 78-17497-01

Step 6 idle timeout (Optional) Specifies a timeout value. Use one of two
commands:
or
• The first command configures a host object timeout
ip-address timeout
value. The valid range is from 30 to 65536 seconds.
• The second command configures an SSG RADIUS
Example: Proxy IP address timeout. The valid range is from 1 to
Router(config-radproxy-timer)# idle 30
180 seconds.
Step 7 exit Exits to SSG-RADIUS-Proxy-Client configuration mode.
Example:
Router(config-radproxy-timer)# exit
Step 8 exit Exits to SSG-RADIUS-Proxy configuration mode.
Example:
Router(config-radproxy-client)# exit
Step 9 Repeat Steps 5 to 9 to configure the AZR as a RADIUS
client.
Step 10 ssg wlan reconnect Enables EAP users to reconnect after logging off or having
idle time out occur.
Example:
Router(config)# ssg wlan reconnect
Monitoring and Maintaining SSG RADIUS Proxy

Perform this task to monitor and maintain SSG Autologon for RADIUS Proxy users.
SUMMARY STEPS
1. clear ssg radius-proxy client-address ip address

2. clear ssg radius-proxy nas-address ip address
3. show ssg auto-domain exclude-profile
4. show ssg binding
5. show ssg connection ip-address service-name
6. show ssg direction
7. show ssg host [ip-address] [count] [username]
8. show ssg next-hop
9. show ssg radius-proxy address-pool address-pool

78-17497-01 67
DETAILED STEPS

Step 1 clear ssg radius-proxy client-address ip address (Optional) Clears all hosts connected to a specific
RADIUS client.
Example: • ip-address—IP address of the RADIUS client to
Router# clear ssg radius-proxy client-address clear.
172.16.0.0
Step 2 clear ssg radius-proxy nas-address ip address (Optional) Clears all hosts connected to a specific
NAS client.
Example: • ip-address—IP address of the NAS client to
Router# clear ssg radius-proxy nas-address clear.
172.16.0.0
Step 3 show ssg auto-domain exclude-profile Displays the contents of an Auto-domain exclusion
profile downloaded from the AAA server. Only
Auto-domain exclude entries entered via CLI are
Example:
Router# show ssg auto-domain exclude-profile
displayed.
Step 4 show ssg binding Displays service names that have been bound to
interfaces and the interfaces to which they have been
bound.
Example:
Router# show ssg binding
Step 5 show ssg connection ip-address service-name Displays the connections of a given host and service
name.
Example: • ip-address—IP address of an active SSG
Router# show ssg connection 19.1.1.19 InstMsg connection. This is always a subscribed host.
• service-name—The name of an active SSG
connection.
Step 6 show ssg direction Displays the direction of all interfaces for which a
direction has been specified.
Example:
Router# show ssg direction
Step 7 show ssg host [ip-address] [count] [username] Displays the information about a subscriber and the
current connections of the subscriber.
Example: • ip-address—(Optional) IP address of the host.
• count—(Optional) Displays the host object
count, including inactive hosts.
• username—(Optional) Displays the usernames
logged into the active hosts.

68 78-17497-01

Step 8 show ssg next-hop Displays the next-hop table.
Example:
Router# show ssg next-hop
Step 9 show ssg radius-proxy address-pool address-pool Displays IP address pool usage for a specific domain
[domain domain-name] [free | inuse] for an entire router.
Example:
Router# show ssg radius-proxy address-pool domain
ssg.com free
Troubleshooting SSG RADIUS Proxy

Perform this task to troubleshoot SSG authentication of RADIUS proxy subscribers.
SUMMARY STEPS
1. debug ssg ctrl-packets

2. debug ssg port-map events
3. debug ssg port-map packets
DETAILED STEPS
Step 1 debug ssg ctrl packets Displays packet contents handled by control modules.
Example:
Router# debug ssg ctrl packets
Step 2 debug ssg port-map events Displays port mapping event messages.
Example:
Router# debug ssg port-map events
Step 3 debug ssg port-map packets Displays port mapping packet contents.
Example:
Router# debug ssg port-map packets
Examples
The following output is generated by using the debug ssg ctrl-packets command when a RADIUS proxy
subscriber logs out of a service:
Router# debug ssg ctrl-packets

78-17497-01 69
Access-request:
3d05h:SSG-CTL-PAK:Received Packet:
sIP=5.5.5.2 sPort=1645 dIP=5.5.5.1 dPort=1645
3d05h:RADIUS:id= 91, code= Access-Request, len= 93
3d05h:RADIUS: authenticator B8 5D 3D 06 E3 2B A2 F3 - 68 E6 C5 E0 F3
1C 60 C7
3d05h:RADIUS: User-Name [1] 10 "user"
3d05h:RADIUS: User-Password [2] 18 *
3d05h:RADIUS: Called-Station-Id [30] 9 "ssg.com"
3d05h:RADIUS: Calling-Station-Id [31] 6 "1234"
3d05h:RADIUS: Framed-Protocol [7] 6 GPRS_PDP_CONTEXT
[7]
3d05h:RADIUS: NAS-Port-Type [61] 6 Virtual
[5]
3d05h:RADIUS: NAS-Port [5] 6 0
3d05h:RADIUS: Service-Type [6] 6 Framed
[2]
3d05h:RADIUS: NAS-IP-Address [4] 6 10.1.1.102
Access-Accept:
3d05h:RADIUS:id= 91, code= Access-Accept, len= 38
3d05h:RADIUS: authenticator 62 57 FE F6 96 65 C1 79 - 18 D7 12 56 EA
28 62 73
[2]
3d05h:RADIUS: Idle-Timeout [28] 6 2000
3d05h:RADIUS: Framed-IP-Address [8] 6 10.1.5.10
Accounting-Request(start) to SSG:
3d05h:SSG-CTL-EVN:Received cmd (4) from proxy-client (5.5.5.2:1646)
3d05h:SSG-CTL-PAK:Received Accounting Packet:
sIP=5.5.5.2 sPort=1646 dIP=5.5.5.1 dPort=1646
3d05h:RADIUS:id= 128, code= Accounting-Request, len= 109
3d05h:RADIUS: authenticator 42 42 D8 7D EC 18 20 42 - 61 B1 03 A2 29
F8 26 56
3d05h:RADIUS: User-Name [1] 10 "user"
3d05h:RADIUS: Acct-Status-Type [40] 6 Start
[1]
3d05h:RADIUS: Acct-Session-Id [44] 10 "00001F5D"
3d05h:RADIUS: Framed-Protocol [7] 6 GPRS_PDP_CONTEXT
[7]
3d05h:RADIUS: Called-Station-Id [30] 9 "ssg.com"
3d05h:RADIUS: Calling-Station-Id [31] 6 "1234"
3d05h:RADIUS: Framed-IP-Address [8] 6 10.1.5.10
3d05h:RADIUS: Authentic [45] 6 RADIUS
[1]
3d05h:RADIUS: NAS-Port-Type [61] 6 Virtual
[5]
3d05h:RADIUS: NAS-Port [5] 6 0
[2]
3d05h:RADIUS: NAS-IP-Address [4] 6 10.1.1.102
3d05h:RADIUS: Delay-Time [41] 6 0
Accounting-Response sent by SSG:

3d05h:SSG-CTL-PAK:Sent accounting response packet:
sIP=?? sPort=56708 dIP=5.5.5.2 dPort=1646
3d05h:RADIUS:id= 128, code= Accounting-response, len= 20
3d05h:RADIUS: authenticator F6 9A 88 38 6C 9D 77 FE - 68 A2 7F 90 9F
DF 15 99

70 78-17497-01
Configuration Examples for SSG Authentication of RADIUS Proxy Subscribers
To display control path events or errors for the host and service logon, use the debug ssg ctrl-events,
debug ssg ctrl-errors, and debug ssg errors commands.
Configuration Examples for SSG Authentication of RADIUS

Proxy Subscribers
• SSG Autologon Using RADIUS Proxy: Examples, page 71
• SSG RADIUS Proxy for CDMA2000: Examples, page 72
• SSG RADIUS Proxy for 802.1x WLAN Deployments: Example, page 76
SSG Autologon Using RADIUS Proxy: Examples

• Enabling SSG AutoLogon Using RADIUS Proxy: Example, page 71
• Configuring Session Identification Attributes: Examples, page 71
• Configuring Timers for RADIUS Proxy: Examples, page 72
Enabling SSG AutoLogon Using RADIUS Proxy: Example

In the following example, SSG is configured as a RADIUS Proxy. Port 1500 is configured as the
authentication port, and port 1499 is configured as the accounting port. A client with the IP address
172.16.0.0 is configured and assigned a shared key secret called “secret1”. An IP address pool is
configured for the domain called “cisco” with a start IP address 172.18.0.0 and an end IP address
172.22.0.0. An idle timeout of 60 seconds is configured. Accounting start-stop is enabled and accounting
start/stop/update packets from all RADIUS clients are proxied to the AAA server. All host objects
received from the RADIUS client at IP address 172.23.0.0 and from the NAS at IP address 172.24.0.0
are deactivated and destroyed.
ssg enable
!
ssg radius-proxy
server-port auth 1500 acct 1499
client-address 172.16.0.0 key secret1
address-pool 172.18.0.0 172.22.0.0 domain cisco
idle-timeout 60
!
forward accounting-start-stop
exit
Configuring Session Identification Attributes: Examples

The following example shows how to configure SSG to identify the specified client session based on
MSID:
ssg enable
ssg proxy-radius

78-17497-01 71
key cisco
session-identifier msid
The following example shows how to configure SSG to identify the specified client session based on the
3GPP2-Correlation-ID attribute:
ssg enable
ssg proxy-radius
key cisco
session-identifier correlation-id
The following example shows how to configure SSG to identify the specified client session based on the
Accounting-Session-ID attribute:
ssg enable
ssg proxy-radius
key cisco
session-identifier accounting-session-id
Configuring Timers for RADIUS Proxy: Examples

The following example shows how to enable SSG RADIUS Proxy and to configure a hand off timeout
of 25 seconds:
ssg enable
ssg proxy-radius
hand-off 25
The following example shows how to enable SSG RADIUS Proxy and to configure an idle timeout of 60
seconds:
ssg enable
ssg proxy-radius
idle 60
The following example shows how to enable SSG RADIUS Proxy and to configure an IP address timeout
of 10 seconds:
ssg enable
ssg proxy-radius
ip-address 60
The following example shows how to enable SSG RADIUS Proxy and to configure an MSID timeout of
3 seconds:
ssg enable
ssg proxy-radius
msid 3 retry 3
SSG RADIUS Proxy for CDMA2000: Examples

• Configuring Multiple RADIUS Server Support: Example, page 73
• Configuring Timers for RADIUS Proxy: Examples, page 72

72 78-17497-01
• Configuring Multiple RADIUS Server Support: Example, page 73

• Configuring Home Agent IP Addresses: Example, page 73
• Removing VSA Types: Examples, page 73
• SSG RADIUS Proxy for CDMA2000 - Complete Configuration: Example, page 73
Configuring Multiple RADIUS Server Support: Example

The following example shows how to configure multiple RADIUS servers in a CDMA2000 network.
Configuring multiple RADIUS servers provides geographical redundancy by sending copies of host
object accounting packets to multiple RADIUS servers.
aaa group server radius billing
server 10.0.0.1 auth-port 1812 acct-port 1813
end
!
aaa server group server radius hotstandby
end
!
aaa accounting network ssg_broadcast_accounting start-stop broadcast group billing group
hotstandby
Configuring Home Agent IP Addresses: Example

The following example shows how to configure a Home Agent with IP address 172.16.0.0 and with a
domain name of “hadomain1”.
ssg enable
ssg proxy-radius
home-agent address 172.16.0.0
home-agent domain hadomain1
Removing VSA Types: Examples

The following example shows how to remove all Cisco VSAs from a RADIUS response sent to a
RADIUS client:
ssg enable
ssg proxy-radius
remove vsa cisco
The following example shows how to remove all 3GPP2 VSAs from a RADIUS response sent to a
RADIUS client:
ssg enable
ssg proxy-radius
remove vsa 3gpp2
SSG RADIUS Proxy for CDMA2000 - Complete Configuration: Example

The following example shows the complete configuration of SSG as a RADIUS proxy in a CDMA2000
network:
!

78-17497-01 73
version 12.3
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname host1
!
aaa new-model
!
aaa group server radius OPERATIONS
!
aaa group server radius RASCUSTOMER
!
aaa authentication login vty line
aaa authentication ppp default local group radius
aaa authorization exec vty none
aaa authorization network default local group radius none
aaa accounting update periodic 1
aaa accounting network ssg_broadcast_accounting start-stop broadcast group OPERATIONS
group RASCUSTOMER
aaa nas port extended
aaa session-id common
enable password password1
!
username cisco password 0 cisco
redundancy
main-cpu
auto-sync standard
no secondary console enable
!
ip subnet-zero
ip cef
no ip domain-lookup
!
ip dhcp-client network-discovery informs 2 discovers 2 period 15
vpdn enable
vpdn search-order domain
!
vpdn-group 1
accept-dialin
protocol pppoe
virtual-template 1
pppoe limit per-mac 1000
pppoe limit per-vc 1000
!
vpdn-group 3
request-dialin
protocol l2tp
domain tunsvc
domain banking
local name dial-tunnel
!
!
!
ssg enable
ssg maxservice 12
ssg accounting interval 300000

74 78-17497-01
ssg bind service vidconf ATM0/0/0.159

ssg bind service banking ATM0/0/0.156
ssg bind service internet-red ATM0/0/0.152
ssg bind service games ATM0/0/0.155
ssg bind service corporate ATM0/0/0.154
ssg bind service shop ATM0/0/0.158
ssg bind service distlearn ATM0/0/0.157
ssg bind service internet-green ATM0/0/0.153
ssg bind service iptv ATM0/0/0.160
ssg bind service internet-blue ATM0/0/0.151
ssg bind direction downlink Ethernet0/0/0
ssg bind direction downlink FastEthernet0/0/0
!
ssg radius-proxy
key cisco
!
key cisco
!
timeouts
idle 60000
!
address-pool 77.77.77.77 77.77.77.88 domain msid3.access
address-pool 88.88.88.88 88.88.88.99 domain corporate3
address-pool 99.99.99.99 99.99.99.111 domain nat-test
address-pool 66.66.66.66 66.66.66.77 domain corporate
home-agent address 4.3.2.1
!
ssg auto-domain
exclude apn corporate
exclude apn corporate3
!
local-profile local1
attribute 26 9 251 "D192.1.1.1"
.
.
.
radius-server host 10.0.48.3 auth-port 1812 acct-port 1813 key troy
radius-server host 10.10.50.181 auth-port 1645 acct-port 1646
radius-server host 10.10.50.180 auth-port 1645 acct-port 1646
radius-server attribute nas-port format d
radius-server key troy
bridge 1 protocol ieee
bridge 1 route ip
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login authentication vty
!

78-17497-01 75
Where to Go Next
SSG RADIUS Proxy for 802.1x WLAN Deployments: Example

The following example shows the configuration of SSG as a RADIUS proxy in a 802.1x WLAN
deployment.
.
.
.
ssg enable
ssg radius-proxy
key cisco
session-identifier auto
!
key cisco
!
timeouts
ip-address 60
!
ssg wlan reconnect
Where to Go Next
To configure other methods of subscriber authentication, refer to the following modules:
• Configuring SSG to Authenticate Web Logon Subscribers
• Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
• Configuring SSG Support for Subnet-Based Authentication
• Configuring SSG for MAC-Address-Based Authentication
• Configuring SSG to Authenticate PPP Subscribers
• Configuring SSG to Authenticate Subscribers with Transparent Autologon

76 78-17497-01
The following sections provide references related to configuring SSG to authenticate RADIUS Proxy
subscribers.
Related Documents
CMDA and CMDA2000 “CDMA Overview” and “CDMA2000 Overview” on the Mobile
Wireless Knowledge Bytes web page:
http://www.cisco.com/warp/public/779/servpro/solutions/wireless_
mobile/training.html
Cisco IOS voice, video and fax commands Cisco IOS Voice, Video, and Fax Command Reference
Cisco IOS voice, video and fax configuration Cisco IOS Voice, Video, and Fax Configuration Guide
SSG commands Cisco IOS Wide-Area Networking Command Reference,
Release 12.4
DHCP accounting DHCP Accounting feature module for Cisco IOS Release 12.2(15)T
Description Link
even more content.
Feature Information for SSG RADIUS Proxy

features that were introduced or modified in Cisco IOS Release 12.2(1) or later appear in the table.
specific commands was introduced, see the command reference documentation.
For information on a feature in this technology that is not documented here, see the “Service Selection
Gateway Features Roadmap.”

78-17497-01 77
Table 7 Feature Information for Configuring SSG to Serve as a RADIUS Proxy

SSG AAA Server Group for Proxy RADIUS 12.3(3)B This feature allows you to configure multiple AAA servers.
12.3(1a)BW You can configure each remote RADIUS server with
12.3(4)T timeout and retransmission parameters. SSG will perform
12.4 failover among the servers in the predefined group.
feature:
• Configuring Multiple RADIUS Server Support,
page 51
SSG Autologon Using Proxy RADIUS 12.2(4)B The SSG AutoLogon Using Proxy RADIUS feature enables
12.2(13)T SSG to act as a RADIUS proxy for non-SSD clients whose
12.4 Access-Requests do not contain VSAs.
feature:
• SSG AutoLogon Using RADIUS Proxy, page 44
• Types of Deployments that Use SSG RADIUS Proxy,
page 46
• Configuring SSG Autologon Using RADIUS Proxy,
page 46
• Monitoring and Maintaining SSG RADIUS Proxy,
page 67
• Troubleshooting SSG RADIUS Proxy, page 69

78 78-17497-01
Table 7 Feature Information for Configuring SSG to Serve as a RADIUS Proxy

SSG EAP Transparency 12.2T In 802.1x WLAN deployments, SSG acts as a RADIUS
12.3(4)T Proxy during Extensible Authentication Protocol (EAP)
authentication between a WLAN AP and the corresponding
AAA server. Using SSG as a RADIUS Proxy in 802.1x
deployments enables WLAN users to access SSG
functionality after they have connected to the AP.
feature:
• Configuring SSG RADIUS Proxy for 802.1x WLAN
Deployments, page 62
• EAP Implementations Supported by SSG, page 63
• SSG EAP Environment, page 63
• EAP Transparency, page 64
• Prevention of IP Address Reuse, page 65
• User Reconnect After Logoff, page 65
• SSG Autologon Using RADIUS Proxy: Examples,
page 71
• SSG RADIUS Proxy for 802.1x WLAN Deployments:
Example, page 76
SSG Proxy for CDMA2000 12.2(15)B This feature enables service selection in CDMA2000
12.2T networks through enhancements to the SSG RADIUS Proxy
12.3(4)T functionality.
feature:
• Configuring SSG RADIUS Proxy for CDMA2000
Deployments, page 55
• Configuring Home Agent IP Addresses: Example,
page 73

78-17497-01 79

80 78-17497-01
Configuring SSG to Authenticate Web Logon
Subscribers
This module describes how SSG can be configured to authenticate Web logon subscribers.
SSG works with in conjunction with SESM, which provides a user interface for subscribers to SSG
services. SESM is a specialized web server that allows users to connect to and disconnect from various
services offered by the service provider. SESM provides subscriber authentication, service selection, and
service connection capabilities.
Module History

and configuration, use the “Feature Information for Configuring SSG to Authenticate Web Logon
Subscribers” section on page 89.
Contents
• Prerequisites for Configuring SSG to Authenticate Web Logon Subscribers, page 81
• Restrictions for Configuring SSG to Authenticate Web Logon Subscribers, page 82
• Information About Web Logon Subscribers, page 82
• How to Configure SSG to Authenticate Web Logon Subscribers, page 84
Prerequisites for Configuring SSG to Authenticate Web Logon

Subscribers
• Before you can perform the tasks in this process, you must enable SSG by completing the steps in
the task Enabling SSG in the “Implementing SSG: Initial Tasks” module.

78-17497-01 81
Configuring SSG to Authenticate Web Logon Subscribers
Restrictions for Configuring SSG to Authenticate Web Logon Subscribers
• Before you can configure SSG to authenticate subscribers you must first configure SESM and the
RADIUS server to support the logon method.
• Before you configure SSG to authenticate web logon subscribers, you should perform the tasks
described in Configuring SSG Interface Direction, Configuring SSG-SESM API Communication,
and Configuring SSG to AAA Server Interaction in the “Implementing SSG: Initial Tasks” module.
• In order to use the SSG TCP Redirect feature, you must install Cisco SESM Release 3.1(1) or higher.
Restrictions for Configuring SSG to Authenticate Web Logon

Subscribers
Only subscribers with a unique IP address can be configured for Web logon.
Information About Web Logon Subscribers

Before you configure SSG authentication of web logon subscribers, you should understand the following
concepts:
• Web Logon, page 82
• TCP Redirection of Unauthenticated Users, page 83
• SSG 3-Key Authentication, page 84
Web Logon
SSG works with in conjunction with SESM, which provides a user interface for subscribers to SSG
services. SESM is a specialized web server that allows users to connect to and disconnect from various
services offered by the service provider. SESM provides subscriber authentication, service selection, and
service connection capabilities. Web service selection enables subscribers to concurrently access
multiple on-demand services from a list of personalized services.
SESM provides subscriber authentication, service selection, and service connection capabilities to
subscribers. Subscribers interact with SESM using a standard Internet browser. They do not need to
download any software or plug-ins to use SESM. After a subscriber successfully authenticates, SESM
presents a list of services that the subscriber is currently authorized to use. The subscriber can gain
access to one or more of those services by selecting them from a web page.
SESM works in conjunction with other network components to provide extremely robust, highly scalable
connection management to Internet services. Internet service providers (ISPs) and network access
providers (NAPs) deploy SESM to provide their subscribers with a web interface for accessing multiple
Internet services. The ISPs and NAPs can customize and brand the content of the web pages and thereby
control the user experience for different categories of subscribers.

82 78-17497-01
Information About Web Logon Subscribers
TCP Redirection of Unauthenticated Users

The SSG TCP Redirect feature redirects certain subscriber traffic to an alternative location that can
handle the packets in a suitable manner. This feature works in conjunction with the SESM captive portal
and web interface. SSG forces subscribers to authenticate before accessing the network or specific
services, and ensures that subscribers are only allowed to access services authorized by the the service
provider.
In TCP redirection, the following events occur:
1. An unauthenticated user opens a browser and attempts to send traffic.
2. SSG determines that the traffic is coming from an unauthenticated user. If SSG is configured for
TCP redirection, the TCP redirection proccess begins. Otherwise, the traffic is dropped.
3. SSG selects a captive portal server (a server configured to respond to redirected packets) from the
captive portal group configured in SESM to handle traffic from unauthenticated users.
4. SSG redirects the user’s traffic to the captive portal server by changing the packet’s destination IP
address and TCP port to those of the captive portal server.
5. The captive portal server responds to the redirected traffic with an http-redirect packet in the
application layer.
6. SSG applies reverse TCP redirection to forward the http-redirect packet back to the unauthenticated
user.
7. The http-redirect packet redirects the unauthenticated user’s browser to the SESM logon page.
8. Once the user is authenticated as a subscriber, the captive portal server can present the subscriber
with a personalized home page, the service provider’s home page, or the the URL originally
requested before the subscriber was authenticated.
For more information about TCP redirection for services, refer to the Configuring SSG Subscriber
Experience Features.
Restrictions for TCP Redirection of Unauthenticated Users

• SSG uses the same captive portal server for each redirection if multiple TCP sessions are redirected
from the same unauthenticated user.
• SSG creates translation entries with the first packet of a TCP session is redirected to a captive portal
server. These translations are cleared when the TCP session terminates or is idle for more than 60
seconds.
• In port-bundle host-key mode with overlapping user IP addresses, TCP redirection only works for
host-keyed servers.
• The traffic that needs to be redirected to the captive portal group is controlled on SSG by specifying
the relevant TCP ports or access lists. Only packets matching these ports and/or access lists are
redirected to the server group.
• TCP redirection only applies to non-PPP users. For more information about PPP subscriber
authentication, refer to the Configuring SSG to Authenticate PPP Subscribers module.

78-17497-01 83
How to Configure SSG to Authenticate Web Logon Subscribers
SSG 3-Key Authentication

The SSG 3-Key Authentication feature enables SSG to authenticate SESM users on the basis of three
keys: username, password, and Mobile Station Integrated Services digital network (MSISDN) number.
Before the introduction of this feature, users logging into SESM were authenticated on the basis of
username and password only (2-key authentication).
When SSG 3-key authentication feature is used, users are required to provide their MSISDN number
(which is typically their phone number), in addition to username and password, at the SESM logon page.
RADIUS attribute 31 (calling-station ID) is used to communicate the MSISDN number in account logon
requests sent from SESM to SSG and in access requests sent from SSG to a AAA server. When 3-key
authentication is used, all host and connection accounting packets for the user contain the MSISDN
number.

The following sections describe how to configure SSG to authenticate web logon subscribers:
• Configuring TCP Redirection for Unauthenticated Subscribers, page 84
• Troubleshooting SSG TCP Redirection for Unauthenticated Subscribers, page 85
Configuring TCP Redirection for Unauthenticated Subscribers

Configuring unauthenticated TCP redirection is an optional task. You could just configure SESM and
AAA server for web logon authentication; refer to SESM documentation for details.
SUMMARY STEPS
1. ssg tcp-redirect
2. server-group group-name
3. server ip-address port
4. exit
5. redirect unauthenticated-user to group-name
DETAILED STEPS

Step 1 ssg tcp-redirect Enables SSG TCP redirect.
Example:
Router(config)# ssg tcp-redirect
Step 2 server-group group-name Defines the group of one or more servers that make up
a named captive portal group and enables
ssg-redirect-group configuration mode.
Example:
Router(config-ssg-redirect)# server-group • group-name—Name of the captive portal group.
RedirectServer

84 78-17497-01

Step 3 server ip-address port Adds a server to a captive portal group.
• ip-address—IP address of the server to add to the
Example: captive portal group.
Router(config-ssg-redirect-group)# server 10.0.0.0
8080
• port—TCP port of the server to add to the captive
portal group.
Step 4 exit Exits ssg-redirect-group configuration mode.
Example:
Router(config-ssg-redirect-group)# exit
Step 5 redirect unauthenticated-user to group-name Selects a captive portal group for redirection of traffic
from unauthenticated users.
Example: • group-name—Name of the captive portal group.
Router(config-ssg-redirect)# redirect
unauthenticated-user to RedirectServer
Troubleshooting SSG TCP Redirection for Unauthenticated Subscribers

Use the following commands to troubleshoot SSG TCP Redirection for Unauthenticated Subscribers.
SUMMARY STEPS
1. show ssg tcp-redirect group [group-name]

2. show tcp-redirect mappings [host-ip-address [interface]]
3. show ssg host ip-address
4. debug ssg tcp-redirect {packet | error | event}
5. debug ssg {ctrl-event | ctrl-error | ctrl-packets | event | error}

78-17497-01 85
DETAILED STEPS

Step 1 show ssg tcp-redirect group [group-name] Lists all configured captive portal groups and
indicates which group receives redirected packets
from unauthenticated users.
Example:
Router# show ssg tcp-redirect group RedirectServer • If the group-name is specified, this command
displays detailed information about that captive
portal group.
Step 2 show tcp-redirect mappings [host-ip-address Displays the redirect mappings currently stored in
[interface]] SSG.
• If the host ip-address is provided, this command
Example: displays detailed redirect mapping information
Router# show tcp-redirect mappings 172.16.0.0 for the specified host.
• The TCP redirect mappings are removed
automatically after the TCP session terminates or
is idle for more than 60 seconds.
• The optional interface argument can be used to
indicate the host’s downlink interface.
Step 3 show ssg host [ip-address] Displays information about a subscriber and current
connections of the subscriber.
Example:

86 78-17497-01
Configuration Examples for SSG Authentication for Web Logon Subscribers

Step 4 debug ssg tcp-redirect {packet | error | event} Use this command to turn on debug information for
the SSG TCP Redirect for Services feature.
Example: • packet—Displays redirection information and
Router# debug ssg tcp-redirect {packet | error | any changes made to a packet when it is due for
event} redirection.
• error—Displays any SSG TCP redirect errors.
• event—Displays any major SSG TCP redirect
events or state changes.
Note This command replaces the debug ssg
http-redirect command.
Step 5 debug ssg {ctrl-event | ctrl-error | ctrl-packets | Use this command to turn on debug information for
event | error} SSG.
• ctrl-event — Displays all event messages for
Example: control modules.
• ctrl-error —Displays all error messages for
control modules.
• ctrl-packets — Displays packet contents
handled by control modules.
• event — Displays all event messages for system
modules.
• error — Displays all error messages for system
modules.
Configuration Examples for SSG Authentication for Web Logon

Subscribers
The following is a sample configuration for a user with IP address 10.1.1.10 connected to SSG via
interface ethernet 1/0. This example includes a basic AAA configuration on SSG (aaa new model,
radius-server host) SSG-SESM communication (ssg radius-helper) and interface binding (ssg
direction downlink):
! enable AAA on the router
aaa new-model
!
! enable SSG on the router
ssg enable
!
! enable ssg tcp-redirection of unauthenticated users

ssg tcp-redirect
server-group group-unauthen-user
server 10.1.1.1 8090
!
redirect unauthenticated-user to group-unauthen-user

78-17497-01 87
Where to Go Next
! bind the interface towards the user as the downlink interface

interface Ethernet 1/0
ip address 10.0.0.1 255.0.0.0
!
! specify the RADIUS server

radius-server host 172.198.1.1 auth-port 1645 acct-port 1646 radius-server key cisco !
Where to Go Next
To configure SSG to authenticate RADIUS Proxy subscribers, refer to Configuring SSG to Serve as a
RADIUS Proxy
The following sections provide references related to configuring SSG to authenticate web logon
subscribers.
Related Documents
Release 12.4
RADIUS configuration tasks Cisco IOS Security Configuration Guide, Release 12.4

88 78-17497-01
Feature Information for Configuring SSG to Authenticate Web Logon Subscribers
Description Link
even more content.
Feature Information for Configuring SSG to Authenticate Web

Logon Subscribers
table.

78-17497-01 89
Feature Information for Configuring SSG to Authenticate Web Logon Subscribers
Table 1 Feature Information for Configuring SSG to Authenticate Web Logon Subscribers

SSG TCP Redirect 12.1(5)DC The SSG TCP Redirect feature forces subscribers to
12.2(4)B authenticate before accessing the network or specific
12.2(8)T services, and ensures that subscribers are only allowed to
12.3T access services authorized by the service provider.
12.4 The following sections provide information about this
feature:
• TCP Redirection of Unauthenticated Users, page 83
• SSG 3-Key Authentication, page 84
• Configuring TCP Redirection for Unauthenticated
Subscribers, page 84
The following commands were introduced by this feature:
ssg tcp-redirect, redirect unauthenticated-user to.

90 78-17497-01
Configuring SSG to Authenticate PPP
Subscribers
SSG supports PPP as a subscriber access protocol. PPP provides router-to-router and host-to-network
connections over both synchronous and asynchronous circuits. This document provides information
about how to configure SSG to support PPP subscribers, including information about PPP Termination
Aggregation (PTA), PTA-multidomain(PTA-MD), virtual-circuit (VC)-to-service-name mapping, and
single signon for PPP users.
Module History

and configuration, use the“Feature Information for Configuring SSG to Authenticate PPP Subscribers”
section on page 102.
Contents
• Information About SSG Authentication of PPP Subscribers, page 92
• How to Configure SSG to Authenticate PPP Subscribers, page 94
Prerequisites
Before you can perform the tasks in this process, SSG must be enabled. See the “Enabling SSG” section
in the Establishing Initial SSG Communication module for more information.
If Cisco Subscriber Edge Services Manager (SESM) is part of your SSG network, SESM and the
RADIUS server must be configured to support the subscriber logon method. See the Cisco Subscriber
Edge Services Manager documentation for information about how to configure SESM.

78-17497-01 91
Configuring SSG to Authenticate PPP Subscribers
Restrictions
If SSG is configured to work with SESM in RADIUS mode, service profiles, subscriber profiles, and
control profiles must be configured on the authentication, authorization, and accounting (AAA) server
before SSG will work. See the <RADIUS Profiles and Attributes for SSG> document for information
about RADIUS profiles and vendor-specific attributes (VSAs) for SSG.
Restrictions
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.
Information About SSG Authentication of PPP Subscribers

Before you configure SSG to authenticate PPP subscribers, you should understand the following
concepts:
• PPP Subscriber Access, page 92
• PPP Termination Aggregation (PTA), page 93
• PTA-Multidomain, page 93
• PTA-MD Exclusion Lists, page 93
• Single Signon for PPP Subscribers, page 93
• VPI/VCI Indexing to Service Profiles, page 94
PPP Subscriber Access

SSG implements Layer 3 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 an incoming packet. An uplink interface is an interface to services;
a downlink interface is an interface to subscribers.
There are two types of access-side interfaces in SSG, SSG-enabled interfaces and interfaces on which
SSG is not enabled. For PPP users, virtual-access interfaces are created and destroyed dynamically, so
for SSG functionality to be applied to traffic on a virtual access interface, SSG must be enabled on the
interface dynamically. The following methods allow SSG to be enabled on an interface dynamically:
• Beginning with Cisco IOS Release 12.2(16)B, the virtual template that is used to create PPP sessions
may be configured as a downlink interface using ssg direction command. All virtual access created
using the virtual template will be configured as SSG-enabled intrefaces
• If the user profile downloaded during PPP authentication has SSG attributes, SSG will automatically
consider that user to be an SSG user and the virtual access interface for that user will be configured
as an SSG-enabled interface
• If the user has a structured username (such as user@domain) and the domain name is a valid SSG
service profile, SSG will create a user to log on to the service domain as the primary service (check
PTA, PTA-MD)
Note that user authentication can be based on a simple username (such as “user”) or structured username
(such as “user@domain.com”). The structured username may be used in the following situations:

92 78-17497-01
Information About SSG Authentication of PPP Subscribers
• to allow access providers to terminate user PPP sessions and logically associate each session with a
particular service
• to allow SSG to bind a user session and its service to the appropriate network side interface
PPP Termination Aggregation (PTA)

PPP Termination Aggregation (PTA) is a PPP method of aggregating IP traffic by terminating PPP
sessions and aggregating the IP traffic into a single routing domain. PTA service selection is based on a
structured name (for example, username@service.com). Users can access only one service.
The following high-level description describes the process for user authentication in a PTA scenario: 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 Attribute-Value (AV) pair “ip:addr-pool”. Network Address
Translation (NAT) is not performed, and all user traffic is aggregated to the remote network.
PTA-Multidomain
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 others and has the capability to support overlapping IP
addresses.
PTA-MD Exclusion Lists

The PTA-MD exclusion list allows you to create a set of domains that you want to exclude from normal
SSG structured username processing. When a PPP user attempts to establish a PPP session using a
domain that is part of the exclusion list, the traffic is treated as a simple username and hence the domain
or service part in the structured username is ignored by SSG. SSG will treat the user as an SSG user if
the user profile has SSG attributes or the corresponding virtual template is configured with SSG.
The PTA-MD exclusion list can be configured on the AAA server or directly on the router by using the
command-line interface (CLI).
Single Signon for PPP Subscribers

SSG creates a host after a successful PPP authentication, but SESM has no knowledge of this host. SSG
user profile caching makes the user profile available to SESM through status queries, providing support
for single signon functionality and for failover from one SESM to another. User profile caching allows
SSG to cache the user profiles for users. The feature is enabled by default.
In order to use single signon for PPP subscribers, you must also enable the single signon feature in
SESM.

78-17497-01 93
How to Configure SSG to Authenticate PPP Subscribers
VPI/VCI Indexing to Service Profiles
Note VPI/VCI indexing to services works only for PPPoA and PPPoEoA (PPP over Ethernet over ATM).
SSG supports 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 configured
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.

To configure SSG to authenticate PPPoA, PPPoE and PPP over Layer 2 Tunneling Protocol (PPPoL2TP)
subscribers , perform the following tasks:
• Configuring SSG Support for PPP Subscribers, page 94 (required)
• Configuring a PTA-MD Exclusion List, page 95 (optional)
• Configuring VPI/VCI Indexing to Services, page 96 (optional)
• Configuring Single Signon for PPP Subscribers, page 97 (optional)
Configuring SSG Support for PPP Subscribers

Perform this task to configure SSG support for PPP subscribers. Configuring SSG to authenticate PPP
users will create hosts when one of the conditions outlined in the “PPP Subscriber Access” section on
page 92, are met.
For PPP subscribers, the virtual template must be configured as the downlink interface. Configuring the
virtual template as a downlink interface is particularly important when SSG users are coming through
CPE and the CPE establishes a PPP session with SSG. In order for the users coming through the CPE to
be treated as SSG users, the PPP interface must be marked as downlink, by configuring the virtual
template as downlink.
All configuration commands that apply to serial interfaces can also be applied to virtual template
interfaces, except shutdown and dialer commands. For further information on virtual templates and how
to configure them, refer to the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fdial_c/fnsprt8/dafvrtmp.ht
m
Perform the following task to create and configure a virtual template interface.
SUMMARY STEPS
1. interface virtual-template number

2. ssg direction downlink
3. ip unnumbered [loopback 1 | ethernet 0]
4. encapsulation ppp
5. virtual-profile

94 78-17497-01
DETAILED STEPS
Step 1 interface virtual-template number Creates a virtual template interface and enters
interface configuration mode.
Example:
Router(config)# interface virtual-template 60
Step 2 ssg direction downlink Sets the direction of the interface.
• A downlink interface is an interface to
Example: subscribers.
Step 3 ip unnumbered [loopback 1 | ethernet 0] Enables IP without assigning a specific IP address on
the LAN.
Example:
Router(config-if)# ip unnumbered loopback 1
Step 4 encapsulation ppp Enables PPP encapsulation on the virtual template
interface.
Example:
Router(config-if)# encapsulation ppp
Step 5 virtual-profile (Optional) Creates a virtual-access interface only if
the inbound connection requires one.
Example:
Router(config-if)# virtual-profile
Configuring a PTA-MD Exclusion List

A PTA-MD exclusion list is used to eliminate parsing of PPP structured usernames during
authentication. A PTA-MD exclusion list can be configured directly on the AAA server or through the
use of the router CLI. Perform this task to configure a PTA-MD exclusion list locally on the router.
SUMMARY STEPS
1. ssg multidomain ppp

2. exclude {domain name | all-domains}
3. download exclude-profile profile-name [password]
4. end
5. show ssg multidomain ppp exclude-list

78-17497-01 95
DETAILED STEPS

Step 1 ssg multidomain ppp Enters SSG PTA-MD configuration mode.
Example:
Router(config)# ssg multidomain ppp
Step 2 exclude {domain name | all-domains} Adds names to the PTA-MD exclusion list.
• domain—Adds a domain to the exclusion list.
Example: • name—Name of the domain to be added to the
Router(config-ssg-ppp-md)# exclude domain xyz
exclusion list.
• all-domains—Excludes all domains; in other
words, disables parsing of PPP structured
usernames.
Step 3 download exclude-profile profile-name [password] Downloads the specified exclusion list from the AAA
server.
Example: • profile-name—Specifies the name for a list of
Router(config-ssg-ppp-md)# download exclude-profile excluded names that may be downloaded from
abc cisco the AAA server.
• password—Specifies the password required to
download the PTA-MD exclusion list from the
AAA server. If no password is entered, the
password used in the previous exclusion list
download will be used to download the exclusion
list.
Step 4 end (Optional) Returns to privileged EXEC mode.
Example:
Router(config-ssg-ppp-md)# end
Step 5 show ssg multidomain ppp exclude-list (Optional) Displays the contents of a PTA-MD
exclusion list.
Example:
Router# show ssg multidomain ppp exclude-list
Configuring VPI/VCI Indexing to Services

To configure VPI/VCI closed user groups, you must map VPI/VCIs to a given service. Perform this task
to map VCs to service names.
SUMMARY STEPS
1. ssg vc-service-map service-name [interface interface-number] start-vpi | start-vpi/vci [end-vpi |

end-vpi/vci] exclusive | non-exclusive
2. exit
3. show ssg vc-service-map

96 78-17497-01
DETAILED STEPS

Step 1 ssg vc-service-map service-name [interface Maps VCs to service names.
interface-number] start-vpi | start-vpi/vci
[end-vpi | end-vpi/vci] exclusive | • The exclusive keyword means that the user has to use
non-exclusive the service specified.
• The non-exclusive keyword means that the user may
Example: optionally choose to override the configuration by
Router(config)# ssg vc-service-map Worldwide using a structured username with a different domain.
3/33 exclusive
Step 2 exit (Optional) Returns to global configuration mode.
Example:
Router(config-auto-domain)# exit
Step 3 show ssg vc-service-map (Optional) Displays VC-to-service-name mappings.
Example:
Router# show ssg vc-service-map
Configuring Single Signon for PPP Subscribers

SSG user-profile caching allows SESM to "recover" the user profiles of PPP users from SSG, which
enables functionality such as single signon. This feature is enabled by default.
Note In order to use single signon for PPP subscribers, you must first enable the single signon feature in
SESM.
Perform this task to enable SSG user-profile caching.
SUMMARY STEPS
1. ssg profile-cache
DETAILED STEPS

Step 1 ssg profile-cache Enables the caching of user profiles for non-PPP
users.
Example:
Router(config)# ssg profile-cache

78-17497-01 97
Configuration Examples for SSG Authentication of PPP Subscribers
Configuration Examples for SSG Authentication of

PPP Subscribers
This section contains the following configuration examples:
• Adding Domains to an Existing PTA-MD Exclusion List: Examples, page 98
• Disabling Parsing of PPP Structured Usernames: Example, page 99
• Service-Name-to-VC Mapping: Example, page 99
• Configuring the Virtual Template to Support PPP Subscribers: Example, page 99
Adding Domains to an Existing PTA-MD Exclusion List: Examples

In the following example, a PTA-MD exclusion list that already includes the domain names of cisco,
motorola, nokia, and voice-stream is downloaded from the AAA server. After the exclusion list is
downloaded, the microsoft and sun domain names are added to the exclusion list.
The exclusion list currently on the AAA server includes cisco, motorola, nokia, and voice-stream. This
exclusion list is in the ACS format.
user = pta_md{
profile_id = 119
profile_cycle = 2
member = SSG-DEV
radius=6510-SSG-v1.1 {
check_items= {
2=password
}
reply_attributes= {
9,253="XPcisco"
9,253="XPmotorola"
9,253="XPnokia"
9,253="XPvoice-stream"
In the following example, the PTA-MD exclusion list is downloaded to the router from the AAA server.
The password to download the exclusion list is cisco. After downloading the PTA-MD exclusion list,
microsoft and sun are added to the list using the router CLI.
ssg multidomain ppp
download exclude-profile pta_md cisco
exclude domain microsoft
exclude domain sun
The enhancements to the exclusion list are then verified.

Router# show ssg multidomain ppp exclude-list
Profile name :pta_md

1 cisco
2 motorola
3 nokia
4 voice-stream
Domains added via CLI :
1 microsoft
2 sun

98 78-17497-01
Disabling Parsing of PPP Structured Usernames: Example

In the following example, parsing of PPP structured usernames is disabled:
exclude all-domains
Service-Name-to-VC Mapping: Example

The following example shows the service name “public” mapped to a VC:
ssg vc-service-map public interface atm3/0 1/37 non-exclusive
The following example shows the service name “public” mapped to a range of VCs:
ssg vc-service-map public interface atm3/0 1/37 1/82 non-exclusive
Configuring the Virtual Template to Support PPP Subscribers: Example

The following example shows a virtual template configured as a downlink interface. Any PPP connection
to SSG that uses this template will be marked as a downlink interface.
interface Virtual-Template1
description PPPoE v-interface
mtu 1492
ip unnumbered Loopback0
ip nat inside
ppp authentication pap chap
!
Basic PPPoA and PPPoE Configuration: Examples

The following configuration examples show how to establish basic PPPoA and PPPoE user connections:
• PPPoA Users: Example, page 99
• PPPoEoA Users: Example, page 100
• PPPoEoE Users: Example, page 101
PPPoA Users: Example

Configure AAA authentication through the RADIUS mechanism.

Configure the PPP IP address on aggregation side

interface Loopback1
ip address 21.6.6.1 255.255.255.0

78-17497-01 99
Configure the IP address pool if SSG is going to assign IP addresses.

ip local pool ppp-pool 21.9.9.2 21.9.9.10
Configure the virtual template.

description "PPP virtual-template for PPP host"
peer default ip address pool ppp-pool
Configure the ATM interface on which PPPoA user comes in.

interface ATM4/0.21 point-to-point
description "Connected to 36/7 for PPP user"
pvc 21/40
encapsulation aal5mux ppp Virtual-Template1
!
PPPoEoA Users: Example


Configure the PPP IP address on aggregation side.

interface Loopback1
ip address 21.6.6.1 255.255.255.0

Configure the PPPoE server using a VPDN group.

vpdn enable
vpdn-group 3
accept-dialin
protocol pppoe
virtual-template 1

Configure the ATM interface on which the PPPoEoA user comes in.
description "Connected to 36/7 for PPPoE user"
ip address 23.6.6.1 255.255.255.0
pvc 23/40
encapsulation aal5snap
protocol pppoe

100 78-17497-01
Where to Go Next
PPPoEoE Users: Example


Configure the PPP IP address on aggregation side.

interface Loopback1
ip address 21.6.6.1 255.255.255.0

Configure the PPPoE server using a VPDN group.

vpdn enable
vpdn-group 3
accept-dialin
protocol pppoe
virtual-template 1

Configure the Ethernet interface on which the PPPoEoE user comes in.
interface fastethernet 1/0
description "Interface for PPPoEoE user"
ip address 23.8.8.1 255.255.255.0
pppoe enable
Where to Go Next

78-17497-01 101
The following sections provide references related to configuring SSG to authenticate PPP subscribers.
Related Documents
Description Link
even more content.
Feature Information for Configuring SSG to Authenticate PPP

Subscribers
table.

102 78-17497-01
Feature Information for Configuring SSG to Authenticate PPP Subscribers
Table 1 Feature Information for Configuring SSG to Authenticate PPP Subscribers

PPP Subscriber Access 12.2(16)B The PPP subscriber access feature supports PPP as a
12.3(4)T subscriber access protocol.
12.4
feature:
• PPP Subscriber Access, page 92
• PPP Termination Aggregation (PTA), page 93
• Configuring SSG Support for PPP Subscribers, page 94
• Configuring Single Signon for PPP Subscribers,
page 97
• Configuring the Virtual Template to Support PPP
Subscribers: Example, page 99
• Basic PPPoA and PPPoE Configuration: Examples,
page 99
ssg direction downlink.
PTA-MD Exclusion List 12.2(15)B The PTA-MD Exclusion List feature allows you to create a
12.3(4)T set of domains that are excluded from normal SSG
12.4 structured username processing.
feature:
• PTA-Multidomain, page 93
• PTA-MD Exclusion Lists, page 93
• Configuring a PTA-MD Exclusion List, page 95
• Adding Domains to an Existing PTA-MD Exclusion
List: Examples, page 98
download exclude-profile (PTA-MD), exclude
(PTA-MD), show ssg multidomain, ppp exclude-list, ssg
multidomain ppp.

78-17497-01 103
Feature Information for Configuring SSG to Authenticate PPP Subscribers

104 78-17497-01
Configuring SSG to Authenticate Subscribers
with Transparent Autologon
The SSG Transparent Autologon feature enables Service Selection Gateway (SSG) to authenticate and
authorize a user on the basis of the source IP address of packets received from the user. This document
describes the SSG Transparent Autologon feature and how to configure SSG to authenticate subscribers
by using transparent autologon.
Module History

and configuration, use the “Feature Information for Configuring SSG to Authenticate Subscribers with
Transparent Autologon” section on page 119.
Contents
• Prerequisites for SSG Transparent Autologon, page 105
• Restrictions for SSG Transparent Autologon, page 106
• Information About SSG Transparent Autologon, page 106
• How to Configure SSG Transparent Autologon, page 110
• Configuration Examples for SSG Transparent Autologon, page 117
Prerequisites for SSG Transparent Autologon

Before you can perform the tasks in this process, you must enable SSG by completing the steps in the
task Enabling SSG in the “Implementing SSG: Initial Tasks” module.

78-17497-01 105
Configuring SSG to Authenticate Subscribers with Transparent Autologon
Restrictions for SSG Transparent Autologon
SSG authorizes the transparent autologon (TAL) user by using the IP address of the user in dotted
notation as a string. Therefore, subscriber profiles must be configured with the IP addresses in dotted
decimal notation as the username on the authentication, authorization, and accounting (AAA) server.
Additionally, all of the subscriber profiles must all be configured with the same password.
Restrictions for SSG Transparent Autologon

• Hosts with overlapping IP addresses are not supported.
Information About SSG Transparent Autologon

Before you configure this feature, you should understand the following concepts:
• Overview of SSG Transparent Autologon, page 106
• SSG Transparent Autologon User-to-Service Packet Flow, page 107
• States of SSG Transparent Autologon Users, page 108
• Switching Between TP and Host User States, page 109
• Benefits of SSG Transparent Autologon, page 110
Overview of SSG Transparent Autologon

The SSG Transparent Autologon feature enables SSG to authenticate subscribers on the basis of the
source IP address of packets received on an SSG downlink interface. Depending on how the feature is
deployed, SSG allows the coexistence of SSG transparent autologon with other logon methods such as
Subscriber Edge Services Manager (SESM) authentication, RADIUS proxy, and PPP session
termination.
When transparent autologon is configured, SSG first creates a temporary entry when it receives the first
IP packet from the unauthenticated user. SSG then sends an authorization request to the AAA server with
the username as the IP address in dotted string format, along with the MAC address (if available) as the
calling-station-id (attribute 31) and the user’s IP address in framed-ip (attribute 8). If the AAA server
finds a valid entry for the user, it authenticates the user and sends an Access-Accept packet. On receiving
the Access-Accept packet, SSG creates a user session on SSG. The functionality of this feature does not
depend on any specific access technology.
Without this feature, SSG always creates a host object for an active user session. With this feature
enabled, an active user in SSG can be of two types:
• User session with host.
• User session without host (known as a transparent pass-through user, or TP).
The type of user session created is determined by the Transparent Pass-Through User (TP) SSG
Account-Info attribute in the subscriber’s profile.
The new user session type (TP user) is useful in situations in which subscribers have a flat-rate access
and there is no need of service selection, accounting, quality of service, prepaid, and so on. The user
session representation of TP requires much less memory than a user session represented with the host
object.

106 78-17497-01
Note Transparent autologon functionality is not applied to packets destined to the default network or SSG’s
IP address.
SSG Transparent Autologon User-to-Service Packet Flow

When SSG Transparent Autologon is configured, a user will be in one of the following states:
• Waiting for authorization (WA)
• Transparent pass-through (TP)
• With host created
• Suspect (SP)
• Unidentified (NR)
These states are described in the following user-to-service packet flow description and in the “States of
SSG Transparent Autologon Users” section on page 108.
Figure 8 is a diagram of the user-to-service packet flow when SSG Transparent Autologon is enabled.
In this sample process, the following events occur:
1. SSG receives the first packet from a user and initiates an authorization request.
2. SSG sends an Access-Request packet to the AAA server with the user’s IP address (in dotted
decimal notation) as the username and a global service password as the password. The user is
marked as waiting for authorization (WA). If the user in WA state continues to send traffic, it is
forwarded or dropped on the basis of the command-line interface (CLI) configuration.
3. SSG receives an answer (either an Access-Accept packet or Access-Reject packet) or no response
from the AAA server. SSG responds to the answer with the following actions:
• Access Accept—If the user profile received as part of the Access-Accept packet has a Transparent
Passthrough (TP) attribute, the user is added to the list of valid users as a transparent pass-through
user (TP), and the user state is changed from WA to TP. If there is no TP attribute in the user profile,
a host is created.
• Access Reject—The user is marked as a suspect user (SP), and the user state is changed from WA
to SP.
• Unidentified User—If there is no response (NR) to the access request from the AAA server, the user
is marked as unidentified (NR).
4. User traffic is allowed, depending on the response from the AAA server and the CLI configuration.
• If the AAA server responds with an Access Accept, traffic will be handled as follows:
• TP user—Traffic from the user will be allowed to access all routable destinations.
• Host—Traffic from the user is allowed according to the services to which the user is logged in.
• If the AAA server responds with an Access Reject, traffic will be handled as follows:
– SP user—Traffic from the user will be allowed to access open garden services and the default
network or it will be TCP-redirected. SP user entries will be deleted after a specified timeout.
• If there is no response from the AAA server, traffic will be handled as follows:
– NR user—Traffic from the user will be allowed on the basis of the CLI configuration. NR user
entries will be deleted after a specified timeout.

78-17497-01 107
Figure 8 User-to-Service Packet Flow
AAA
2 3 Radius
IP IP
1 4
98658
SSG
States of SSG Transparent Autologon Users

The following sections describe the SSG transparent autologon user states:
• User with Host, page 108
• Transparent Pass-Through User (TP), page 108
• User Waiting for Authorization (WA), page 109
• Suspect User (SP), page 109
• Unidentified User (NR), page 109
User with Host

When the SSG Transparent Autologon feature is configured, the host object user can be logged on in one
of three ways:
1. An Access-Accept packet is received from the AAA server for the TAL authorization request by
SSG, and the response does not have the TP attribute. SSG creates a host object for this user, and if
there are any autoservices in the profile, it logs the user in to the autoservices. (Autoservices are
services that a user can log onto as soon as SSG account logon is complete.) This type of logon is
useful if the user’s access to a service is static and authentication is required from the user.
2. An Access-Reject packet is received from the AAA server for the TAL authorization request, and
SSG marks the subscriber as an SP user. When the next packet is received from the same user, SSG
attempts a TCP-redirect (if configured) to SESM, and SESM displays a logon page for the user. If
the user account logon through SESM is successful, SSG creates a host object. The user is removed
from the SP list.
Transparent Pass-Through User (TP)

An Access-Accept packet is received from the AAA server for the TAL authorization request and the
user profile response has the Transparent Pass-Through (TP) attribute configured. In this case, SSG does
not create hosts; instead, SSG adds the user to the TP user table.
For TP users, SSG honors only idle timeout and session timeout attributes from the user-profile. If other
attributes are present, SSG ignores them.
The TP user model is useful for flat-rate users, where no accounting or differentiated services are
required. Accounting records are not sent for the transparent pass-through users, even if accounting is
enabled on the SSG. Traffic is forwarded to the service network on the basis of global routing table.

108 78-17497-01
For TP users, idle timeouts and session timeouts can be configured either in the user profiles or globally
though the CLI. The idle timeout and session timeout values configured in the user profile take
precedence over the values configured globally.
User Waiting for Authorization (WA)

While SSG is waiting for the AAA server;s response to the TAL request, the user is treated in a state
known as waiting for authorization (WA). If a user is marked as WA, packets received from the user are
dropped or forwarded, depending on the CLI configuration. By default, packets are forwarded.
The number of WA users increases if the AAA server response is very slow or the rate of authorization
is high.
If the number of WA users exceeds a configured value, no new WA users are added, and any packet that
causes SSG to send an authorization request is dropped in the Cisco Express Forwarding (CEF) path.
This also means that any new user will not undergo transparent autologon unless the number of WA users
falls below the configured threshold.
To protect the AAA server from processing too many requests per second, SSG can be configured to
throttle the number of access requests per second. If the maximum throttle rate is reached, a syslog
message is generated.
Suspect User (SP)

If an Access-Reject packet is received from the AAA server for the TAL authorization request, that user
is marked as a suspect user (SP). Packets received from an SP user are TCP-redirected or dropped (if
tcp-redirection is not enabled). The user remains marked as SP for a configurable length of time (one
hour by default).
Too many SP users can cause SSG to consume all of its memory in maintaining the SP cache. To counter
this situation, SSG provides a CLI command to configure the maximum number of SP users maintained
by SSG. If the SP user count exceeds this maximum value, a syslog message is generated and SSG does
not add any new SP users.
Unidentified User (NR)

If there is no response from the AAA server for the TAL authorization request and the request times out,
the user’s state is changed from WA to no response (NR). SSG logs a syslog message when there is no
response from the AAA server.
Packets received from NR users are either TCP-redirected or forwarded using global routing table, or
dropped depending on the CLI configuration. By default, packets received from NR users are
TCP-redirected and/or dropped (if TCP-redirection is not configured).
Switching Between TP and Host User States

A TP (flat-rate) user can log on through SESM or some external device. When this occurs, SSG creates
the host object for this user and removes the entry from the TP user list.
In the event that an external device sends an account logoff request to SSG, SSG will log the user as a
transparent pass-through user when SSG receives the next IP packet from this user.

78-17497-01 109
How to Configure SSG Transparent Autologon
Benefits of SSG Transparent Autologon

With the SSG Transparent Autologon feature, SSG provides the following functionality:
• Always-on access to network services for specific classes of users.
• Pay-per-use access to network services that are subject to explicit signon and authentication
procedures managed by SSG and SESM.

• Configuring SSG Transparent Autologon, page 110
• Configuring the AAA Subscriber Profile for SSG Transparent Autologon Subscribers, page 112
• Monitoring and Maintaining SSG Transparent Autologon, page 112
• Troubleshooting SSG Transparent Autologon, page 115
Configuring SSG Transparent Autologon

Perform this task to configure SSG Transparent Autologon.
SUMMARY STEPS
1. ssg login transparent

2. authorization list list-name
3. authorization pending maximum number
4. authorization rate-limit number
5. packet drop during-authorization
6. user suspect maximum number
7. user suspect timeout minutes
8. user unidentified timeout minutes
9. user unidentified traffic permit
10. exit

110 78-17497-01
DETAILED STEPS

Step 1 ssg login transparent Enables SSG Transparent Autologon and enters transparent
autologon configuration mode.
Example:
Router(config)# ssg login transparent
Step 2 authorization list list-name (Optional) Specifies the server group to be used for
authorization of SSG transparent autologon users.
Example: • If no server group is specified, SSG uses the default
Router(config-login-transparent)# authorization server group for authorization. The default server group
list list1 is the list of RADIUS servers defined as “radius-server
host...”.
• If a server group is specified, SSG sends a transparent
authorization request to that server group.
Step 3 authorization pending maximum number (Optional) Specifies the maximum number of SSG TAL
access requests that can be pending.
Example: • When the number of access requests reaches the
Router(config-login-transparent)# authorization configured limit, any packets that would cause SSG to
pending maximum 1200 send a new RADIUS request are dropped at the CEF
path, and SSG generates a syslog message.
Step 4 authorization rate-limit number (Optional) Specifies the number of SSG new TAL
authorization requests sent per second.
Example: • The rate must be based on the number of requests the
Router(config-login-transparent)# authorization AAA server can handle per second.
rate-limit 100
• If the number of requests per second exceeds the
configured limit, SSG logs a syslog message. The
syslog message is logged only once for each time the
rate limit value is reached.
Step 5 packet drop during-authorization (Optional) Specifies that packets received from the user
during WA state (that is, during authrization) will be
dropped.
Example:
Router(config-login-transparent)# packet drop
during-authorization
Step 6 user suspect maximum number (Optional) Specifies the maximum number of suspect users
(SP) that can be added to the suspect user list.
Example:
Router(config-login-transparent)# user suspect
maximum 1000
Step 7 user suspect timeout minutes (Optional) Specifies the maximum length of time a suspect
user (SP) remains in the suspect user list.
Example: • The default timeout is 3600 seconds.
Router(config-login-transparent)# user suspect
timeout 600

78-17497-01 111

Step 8 user unidentified timeout minutes (Optional) Specifies the maximum length of time a user
remains in the no response (NR) state.
Example: • An unidentified user is marked NR if there is no
Router(config-login-transparent)# user response from the AAA server to an authorization
unidentified timeout 600 request and the authorization request times out.
• When the timeout value is reached, any new traffic
received by SSG from the user triggers the transparent
logon procedure.
Step 9 user unidentified traffic permit (Optional) Specifies that packets received by an
unidentified (NR) user are to be forwarded.
Example:
Router(config-login-transparent)# user
unidentified traffic permit
Example:
Router(config-login-transparent)# exit
Configuring the AAA Subscriber Profile for SSG Transparent Autologon

Subscribers
User-profiles for all the users that need to be authorized using TAL needs to be configured with username
equal to the IP address as a doted-notation in string format. This is true if there is no script running on
the AAA server to change the usernames.
User profiles for flat-rate users must include the Transparent Passthrough User (TP) attribute.
Monitoring and Maintaining SSG Transparent Autologon

Perform this task to monitor and maintain SSG Transparent Autologon. Step 1 is required. Steps 2
through 10 are optional and need not be performed in any particular order.
SUMMARY STEPS
1. enable
2. show ssg user transparent
3. clear ssg user transparent all
4. show ssg user transparent authorizing [count]
5. show ssg user transparent passthrough [ipaddress | count]
6. clear ssg user transparent passthrough {all | ipaddress}
7. show ssg user transparent suspect [count]
8. clear ssg user transparent suspect {all | ipaddress}
9. show ssg user transparent unidentified [count]

112 78-17497-01
10. clear ssg user transparent unidentified {all | ipaddress}
DETAILED STEPS

Example:
Router# enable
Step 2 show ssg user transparent Displays all users (pass-through, suspect, unidentified, or
waiting for authorization) in a table of IP addresses and user
types.
Example:
Router# show ssg user transparent
Step 3 clear ssg user transparent all Deletes all pass-through, suspect, unidentified, and
authorizing users.
Example:
Router# clear ssg user transparent all
Step 4 show ssg user transparent authorizing [count] Displays a list of users for whom authorization is in
progress and are waiting for AAA response (WA users).
Example:
Router# show ssg user transparent authorizing
Step 5 show ssg user transparent passthrough Displays a list of transparent (TP) users.
[ipaddress | count]
Example:
Router# show ssg user transparent passthrough
Step 6 clear ssg user transparent passthrough {all | Deletes pass-through user entries.
ipaddress}
Example:
Router# clear ssg user transparent passthrough
all
Step 7 show ssg user transparent suspect [count] Displays a list of all suspect (SP) user IP addresses.
Example:
Router# show ssg user transparent suspect count
Step 8 clear ssg user transparent suspect {all | Deletes suspect (SP) user entries.
ipaddress}
Example:
Router# clear ssg user transparent suspect all

78-17497-01 113

Step 9 show ssg user transparent unidentified [count] Displays a list of all users for whom there is no response
from AAA to the authorization request (NR users).
Example:
Router# show ssg user transparent unidentified
Step 10 clear ssg user transparent unidentified {all | Deletes users for whom there is no response from AAA to
ipaddress} the authorization request (NR users).
Example:
Router# clear ssg user transparent unidentified
all
Example
The following examples show sample output for commands that can be used to monitor SSG transparent
autologon:
show ssg user transparent Output: Example

The following is sample output from the show ssg user transparent command:
Router# show ssg user transparent
10.10.10.10 Passthrough
11.11.11.11 Suspect
120.120.120.120 Authorizing
### Total number of transparent users: 3
show ssg user transparent authorizing Output: Example

The following is sample output from the show ssg user transparent authorizing command with the
count keyword:
Router# show ssg user transparent authorizing count
### Total number of WA users: 1
show ssg user transparent passthrough Output: Example

The following is sample output from the show ssg user transparent passthrough command for the user
having IP address 10.10.10.10:
Router# show ssg user transparent passthrough 10.10.10.10
User IP Address: 10.10.10.10
Session Timeout: 200 (seconds)
Idle Timeout: 100 (seconds)
User logged on since: *16:33:57.000 GMT Mon May 19 2003
User last activity at: *16:33:57.000 GMT Mon May 19 2003
Current Time: *16:35:17.000 GMT Mon May 19 2003

114 78-17497-01
show ssg user transparent suspect Output: Example

The following is sample output from the show ssg user transparent suspect command with and without
the count keyword:
Router# show ssg user transparent suspect count
### Total number of SP users: 1
Router# show ssg user transparent suspect
94.0.0.1
### Total number of SP users: 1
show ssg user transparent unidentified Output: Example

The following is sample output from the show ssg user transparent unidentified command with and
without the count keyword:
Router# show ssg user transparent unidentified count
### Total number of NR (Unidentified) users: 1
Router# show ssg user transparent unidentified
93.0.0.1
### Total number of NR (Unidentified) users: 1
Troubleshooting SSG Transparent Autologon

Perform this task to display logon control events or errors.
SUMMARY STEPS
1. debug ssg transparent login {errors | events} [ipaddress]
DETAILED STEPS

Step 1 debug ssg transparent login {errors | events} Displays transparent logon control events or errors.
[ipaddress]
Example:
Router# debug ssg transparent login
Example
The following examples show sample output for the debug ssg transparent logon command. The output
is self-explanatory.
Unidentified (NR) User: Example

*Jan 15 12:34:47.847:SSG-TAL-EVN:100.0.0.2:Added entry successfully

78-17497-01 115
*Jan 15 12:34:47.847:SSG-TAL-EVN:100.0.0.2:Attempting authorization
*Jan 15 12:34:47.847:SSG-TAL-EVN:100.0.0.2:Attempting to send authorization request
*Jan 15 12:35:09.711:SSG-TAL-EVN:100.0.0.2:Authorization response received
*Jan 15 12:35:09.711:SSG-TAL-EVN:100.0.0.2:Authorization timedout. User statechanged to

unidentified
*Jan 15 12:35:09.711:%SSG-5-SSG_TAL_NR:SSG TAL:No response from AAA server. AAA server

might be down or overloaded.
*Jan 15 12:35:09.711:SSG-TAL-EVN:100.0.0.2:Start SP/NR entry timeout timer for 10 mins
Transparent Pass-Through (TP) User: Example

*Jan 15 12:40:39.879:SSG-TAL-EVN:100.0.0.2:Parsing profile for TP attribute
*Jan 15 12:40:39.879:SSG-TAL-EVN:100.0.0.2:TP attribute found - Transparent user
*Jan 15 12:40:39.879:SSG-TAL-EVN:100.0.0.2:Stop SP/NR timer
*Jan 15 12:40:39.879:SSG-TAL-EVN:100.0.0.2:Idle timer started for 0 secs
*Jan. 15 12:40:39.879:SSG-TAL-EVN:100.0.0.2:Session timer started for 0 secs
Suspect User (SP): Example

*Jan 15 12:43:25.939:SSG-TAL-EVN:10.10.10.10:Access reject from AAA server. Userstate

changed to suspect
*Jan 15 12:43:25.939:SSG-TAL-EVN:10.10.10.10:Start SP/NR entry timeout timer for 60 mins
Clear All Users: Example

The following is sample output for the debug ssg transparent login command when it is used after all
transparent autologon users have been cleared by using the clear ssg user transparent all command.
*Jan 15 12:47:08.943:SSG-TAL-EVN:10.10.10.10:Entry removed
*Jan 15 12:47:08.943:SSG-TAL-EVN:10.10.10.10:Stop Idle timer
*Jan 15 12:47:08.943:SSG-TAL-EVN:10.10.10.10:Stop session timer

116 78-17497-01
Configuration Examples for SSG Transparent Autologon
Configuration Examples for SSG Transparent Autologon

This section provides the following configuration examples:
• SSG Transparent Autologon Configuration: Example, page 117
• AAA User Profile Configuration for Transparent Passthrough (TP) Users: Example, page 117
• AAA User Profile Configuration for Users with Hosts: Example, page 118
SSG Transparent Autologon Configuration: Example

The following example shows the how to enable and configure SSG Transparent Autologon.
!
aaa new-model
!
! creates aaa-list for TAL authorization
aaa group server radius TAL_LIST
!
! The following commands configure SSG transparent autologon.
ssg login transparent
authorization list TAL_LIST
authorization pending maximum 1200
authorization rate-limit 100
user suspect timeout 600
user suspect maximum 1000
user unidentified timeout 600
user unidentified traffic permit
packet drop during-authorization
!
!
AAA User Profile Configuration for Transparent Passthrough (TP) Users:

Example
The following example shows the configuration of the AAA user profile for a transparent pass-through
user. Note that the username is the user’s IP address.
10.0.0.1 Password = "servicecisco"
Cisco-SSG-Account-Info = "TP",

78-17497-01 117
Where to Go Next
Idle-Timeout = 600
Session-Timeout = 3600
AAA User Profile Configuration for Users with Hosts: Example

The following example shows the configuration of the AAA user profile for a user with a host object
(pay-per-use user). Note that the username is the user’s IP address.
10.0.0.1 Password = "servicecisco"
Cisco-SSG-Account-Info = "Ainternet-Service",
Idle-Timeout = 600
Session-Timeout = 3600
Where to Go Next
To configure SSG to authenticate RADIUS Proxy subscribers, refer to the Configuring SSG to Serve as
a RADIUS Proxy module.
The following sections provide references related to configuring SSG to authenticate TAL subscribers.
Related Documents
Release 12.4

118 78-17497-01
Feature Information for Configuring SSG to Authenticate Subscribers with Transparent Autologon
Description Link
even more content.
Feature Information for Configuring SSG to Authenticate

Subscribers with Transparent Autologon
table.

78-17497-01 119
Feature Information for Configuring SSG to Authenticate Subscribers with Transparent Autologon
Table 1 Feature Information for Configuring SSG to Authenticate Subscribers with Transparent Autologon

SSG Transparent Autologon 12.3(1a)BW The SSG Transparent Autologon feature enables Service
12.3(3)B Selection Gateway (SSG) to authenticate and authorize a
12.3(7)T user on the basis of the source IP address of packets
12.4 received from the user.
feature:
• Overview of SSG Transparent Autologon, page 106
• SSG Transparent Autologon User-to-Service Packet
Flow, page 107
• States of SSG Transparent Autologon Users, page 108
• Switching Between TP and Host User States, page 109
• Benefits of SSG Transparent Autologon, page 110
• Configuring SSG Transparent Autologon, page 110
• Configuring the AAA Subscriber Profile for SSG
Transparent Autologon Subscribers, page 112
• Monitoring and Maintaining SSG Transparent
Autologon, page 112
• Troubleshooting SSG Transparent Autologon,
page 115
clear ssg user transparent, show ssg user transparent,
ssg login transparent, .

120 78-17497-01
Configuring SSG to Authenticate Subscribers
Automatically in the Service Domain
The SSG AutoDomain feature allows Service Selection Gateway (SSG) to authenticate subscribers
automatically in the service domain. The AutoDomain feature allows a user to be connected to a service
automatically on the basis of either the access point name (APN) or the domain part of a structured
username, which is specified in an Access-Request packet. In this mode, authentication of the user is not
performed at the network access provider (NAP) authentication, authorization, and accounting (AAA)
server but instead in the service domain (for example, the AAA server within a corporate network).
Module History

and configuration, use the “Feature Information for Configuring SSG to Authenticate Subscribers
Automatically in the Service Domain” section on page 132.
Contents
• Prerequisites for SSG AutoDomain, page 121
• Restrictions for SSG AutoDomain, page 122
• Information About SSG AutoDomain, page 122
• How to Configure SSG AutoDomain, page 127
• Configuration Examples for SSG AutoDomain, page 130
Prerequisites for SSG AutoDomain

Before you configure SSG AutoDomain, SSG must be enabled.

78-17497-01 121
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
Restrictions for SSG AutoDomain
If SSG is configured to work with SESM in RADIUS mode, service profiles, subscriber profiles, and
control profiles must be configured on the AAA server before SSG will work. See the “RADIUS Profiles
and Attributes for SSG” document for information about RADIUS profiles and attributes for SSG.
Subscriber Edge Services Manager (SESM) and the AAA server must be configured to support SSG
AutoDomain.
Restrictions for SSG AutoDomain

Loose coupling of hosts objects and Packet Data Protocol (PDP) contexts (when Gateway GPRS Support
Node (GGSN) is a RADIUS client) can cause some error conditions that cannot be cleanly recovered
without end-user intervention (such as reconnecting).
Information About SSG AutoDomain

The SSG AutoDomain feature allows SSG to provide subscriber authentication for services. To
configure SSG AutoDomain, you need to understand the following concepts:
• Overview of SSG AutoDomain, page 122
• IP Address Assignment, page 123
• SSG AutoDomain Basic and Extended Modes, page 124
• SSG AutoDomain Service Types, page 124
• Access Point Names, page 124
• AutoDomain Name Selection, page 125
• Multiple Local IP Pools, page 125
• Primary AutoDomain Service Termination, page 126
• SSG AutoDomain and NAT, page 126
• Benefits of SSG AutoDomain, page 127
Overview of SSG AutoDomain

The SSG AutoDomain feature allows SSG to authenticate subscribers in the service domain.
The SSG AutoDomain feature enables users to connect to a service automatically on the basis of either
access point name (APN) or the domain part of the structured username specified in an Access-Request
packet. When SSG AutoDomain is configured, user authentication is not performed by the Network
Access Provider (NAP), but instead in the service domain (for example, at an authentication,
authorization, and accounting (AAA) server within a corporate network).
Using SSG AutoDomain, you can automatically log a user on to a service on the basis of either the APN
or the domain portion of the structured username. The domain portion of the structured username is the
portion after the @ in the username. For example, in the username “abc@cisco.com”, “cisco.com” is the
domain name.
Users can bypass SESM and access a service, such as a corporate intranet. SSG AutoDomain is also
supported for users logging in from SESM.

122 78-17497-01
SSG AutoDomain makes it possible to log a user on to either Layer 2 Tunnel Protocol (L2TP) or proxy
services. The username and password used to log a user on with AutoDomain are the same username and
password provided by the end-user device when the end user originally logged into the network. The
username and password may be entered manually by the end user or preconfigured on the end-user
device. The password may also be dynamically generated.
SSG AutoDomain does not require SSG vendor specific attributes (VSAs) when using a domain name
as a means to determine which service the user is to be logged on to. AutoDomain uses a heuristic to
determine the service onto which the user is to be logged. When AutoDomain is used, the host object is
not activated until the user has been successfully authenticated with the service. If the autoservice
connection fails for any reason, the user logon is rejected, and an Access-Reject packt is returned to the
client device.
By default, SSG first checks for an AutoDomain name using the APN. The APN is normally conveyed
in the Called-Station-ID attribute. If the AutoDomain name is not in the Called-Station-ID attribute, SSG
looks for the name in the NAS-Identifier attribute. If the AutoDomain name cannot be extracted from
the APN, SSG attempts to extract it from the structured username.
If AutoDomain is enabled and the received Access-Request packet specifies an APN, SSG uses this APN
for AutoDomain selection unless it is a member of the APN AutoDomain exclusion list. If an
AutoDomain is not selected based on the APN, SSG uses the structured username. If a structured
username is not supplied, or the supplied structured username is a member of the domain name exclusion
list, no AutoDomain is selected, and normal SSG user logon proceeds. You can override these
AutoDomain selection defaults by configuring the select command in SSG-auto-domain mode. You can
define the APN AutoDomain exclusion list and the domain name exclusion list with the exclude
command in SSG-auto-domain mode.
When AutoDomain is enabled, an AutoDomain profile is downloaded from the local AAA server. The
AutoDomain profile can be a service profile or a virtual user profile, depending on whether you
configure AutoDomain in basic or extended mode. This profile is specified as an outbound service, and
the password is the globally configured service password.
IP Address Assignment
Host objects created as a result of AutoDomain logon are assigned an IP address from one of the
following sources:
• From the client device. If the IP address is assigned by the client device before authentication, each
Access-Request packet received from the client device has an IP address in the Framed-IP field.
If after authentication, the client device uses DHCP to assign an IP address to the user once the user
has been successfully authenticated. This IP address is signaled to SSG in the Accounting start
packet.
• From the Gateway GPRS Support Node (GGSN). Each Access-Request packet received from GGSN
has an IP address in the Framed-IP field.
• From the Corporate Network: The AAA server in the corporate network authenticates the user and
sends an Access-Accept packet. In the Access-Accept packet, the AAA server sends an IP address
in the Framed-IP field.
• From the SSG local pool: In RADIUS-proxy mode you can configure IP address pools. If an IP
address is not assigned from any of the above sources, the IP address is allocated from the SSG local
pool.

78-17497-01 123
SSG AutoDomain Basic and Extended Modes

You can configure SSG AutoDomain in basic or extended mode. In basic mode, the AutoDomain profile
downloaded from the AAA server is a service profile. In extended AutoDomain mode the profile
downloaded from the AAA server is a “virtual user” profile that contains one primary service to an
authenticated service such as a proxy or tunnel. The virtual user profile defines the AutoDomain service
as a primary service. Connection to this primary service occurs as it does for basic AutoDomain; that is,
the host object is not activated until the user has been authenticated at the proxy or tunnel service.The
virtual user profile can also have other auto-logon services along with the primary service. Extended
mode is for deployments in which the extra functionality introduced by SESM is to be utilized. The
presence of SESM allows the user to switch among the services in the virtual user profile. If the virtual
user profile does not have a primary service or if the autoservice is not authenticated, the AutoDomain
logon is rejected.
SSG AutoDomain Service Types

The AutoDomain service profile can be a proxy, VPDN, tunnel service, or pass-through. If the
downloaded AutoDomain service profile is a proxy service, SSG authenticates the user to the appropriate
domain AAA server with the authentication information found in the Access-Request packet received
from the RADIUS client. If the downloaded AutoDomain service profile is a tunnel service, a PPP
session is regenerated into an L2TP tunnel for the selected service.
If no SSG-specific attributes are returned indicating the type of service required, SSG treats the service
as a virtual private dialup network (VPDN) service and adds the following attributes to the service
profile:
• Service network (R) as 0.0.0.0;0.0.0.0
• Service mode as concurrent (MC)
• Service type as tunnel (TT)
SSG then regenerates the PPP session for the specified service.
SSG AutoDomain attempts to log the user onto the remote service using the username and password
specified in the original Access-Request. If selection of the AutoDomain is based on the realm part of
the username, only the “user” part of the name is used unless the “X” attribute is present in the service
profile. For VPDN-only type services (where no SSG attributes are present), it is not possible to specify
use of the full structured username.
It is possible to configure an unauthenticated service as the AutoDomain service in basic mode or the
primary service in extended mode AutoDomain. However, in these cases no user authentication occurs
because in AutoDomain authentication at the NAP, the AAA server is bypassed.
Access Point Names

An APN identifies a packet data network (PDN) that is configured on and accessible from a GGSN. An
access point is identified by its APN name. The Global System for Mobile Communications (GSM)
standard 03.03 defines the following two parts of an APN:
• APN Network Identifier
• APN Operator Identifier

124 78-17497-01
The APN Network Identifier is mandatory. The name of an access point in the form of an APN Network
Identifier must correspond to the fully qualified name in the Domain Name System (DNS) configuration
for that network, and it must also match the name specified for the access point in the GGSN
configuration. The GGSN also uniquely identifies an APN by an index number.
The APN Operator Identifier is an optional name that consists of the fully qualified DNS name, with the
ending “.gprs”.
The access points that are supported by the GGSN are preconfigured on the GGSN. When a user requests
a connection in the GPRS network, the APN is included in the Create Packet Data Protocol (PDP)
Request message. The Create PDP Request message is a GPRS Tunneling Protocol (GTP) message that
establishes a connection between the Serving GPRS Support Node (SGSN) and the GGSN.
An APN has several attributes associated with its configuration that define how users can access the
network at a specified entry point. For more information about configuring APNs, see the APN Manager
Application Programming Guide.
Note If the Access-Request packet received from the RADIUS client does not contain the
Called-Station-ID (attribute 30), then the NAS-Identifier (attribute 32), if provided, is treated as the
APN name.
AutoDomain Name Selection

When AutoDomain is enabled, SSG uses the following algorithm to determine the AutoDomain name:
• If the received Access-Request packet contains an APN (attribute 30), this APN is used for
AutoDomain selection unless it is a member of the APN AutoDomain exclusion list.
• If APN is not selected using attribute 30, the NAS-Identifier (attribute 32) is used, unless it is a
member of the APN AutoDomain exclusion list.
• If an AutoDomain is not selected based on APN, the structured username is used (attribute 1).
• If a valid AutoDomain is not found in one of these attributes, AutoDomain is not selected, and
normal SSG user logon proceeds.
You can configure SSG to override the default AutoDomain selection rules—that is, force it to be based
on any available attribute.
Note that for AutoDomain selection based on username, SSG expects the username to be a structured
username and attempts to extract the domain from it. When SSG looks for the domain name and the
username is unstructured (that is, it does not contain ‘@’), the AutoDomain selection is deemed to have
failed, and SSG does not use the unstructured name. Note also that SSG does not attempt to extract a
domain from any other attribute.
Multiple Local IP Pools

By default for AutoDomain, SSG assigns the IP address to a host object for the primary AutoDomain
service (unless the IP address has already been assigned by some other mechanism). You can override
the default by using a CLI command instructing SSG to use Network Address Translation (NAT). In this
case SSG assigns an IP address from a locally configured pool and performs NAT on the service. You
can override the NAT/no-NAT behavior, on a per-AutoDomain service basis.
You can configure multiple local SSG IP pools for the same domain name, and also multiple global
pools; for example:

78-17497-01 125
ssg radius-proxy
address-pool 1.1.1.1 1.1.2.2
address-pool 1.1.2.3 1.1.3.3
address-pool 1.1.3.4 1.1.4.4 acme.com
address-pool 1.1.4.5 1.1.5.5 acme.com
!
This functionality does not allow overlapping ranges within the same domain or global set. However, no
restrictions are imposed on pools in one domain overlapping with those in another domain.
Primary AutoDomain Service Termination

By default, if the connection to the primary AutoDomain service is terminated, SSG terminates the
session by destroying the host object. You can override this default behavior by using the no
auto-session-terminate command. When you configure this command, SSG does not necessarily
terminate the session when it loses the primary connection. If the host object IP address originated from
the primary AutoDomain service, and the connection to this service is lost, the IP address is no longer
valid. Because SSG has no mechanism to reassign a host object IP address during an active session, SSG
terminates the session at this point.
SSG AutoDomain and NAT

By default, the IP address assigned to a host object is that received from the primary AutoDomain service
(unless the IP address has already been assigned by some other mechanism). You can override the default
by configuring SSG to use NAT. In this case SSG assigns an IP address from a local pool (if configured)
and performs NAT on the service. If NAT is configured but no suitable local pool is configured, SSG
assumes that the IP address is being assigned by the client device via the Accounting start packet. Again
NAT will be performed between the IP addresses provided by the service domain and the client device.
You can override the NAT/no-NAT behavior as needed, on a per-AutoDomain service basis.
You can enable NAT for an AutoDomain service using the nat user-address command. When this
command is in effect, SSG either attempts to allocate an IP address for an AutoDomain host from a local
SSG pool or waits for one to be assigned by the client device; NAT then takes place toward the
AutoDomain service. However, this configuration is global; that is, you either always or never perform
NAT to all AutoDomain services.
Table 2 describes the Service-Info attribute tha can be used in the AutoDomain service profile to
configure NAT behavior on a per-AutoDomain basis. This VSA allows the NAT configuration for a given
auto-domain service to override the global configuration.
Table 2 Service-Info Vendor-Specific Attribute
Subattribute
Attribute ID Vendor ID ID and Type Attribute Name Subattribute Data
26 9 251 NAT user address C—Service-Info code for NAT
Service-Info user address.
0 or 1—Disable or enable NAT
of user address respectively.

126 78-17497-01
How to Configure SSG AutoDomain
The value of attribute C can be 0 or 1 depending on whether NAT mode is being disabled or enabled,
respectively. Any value received for this attribute in a service profile takes precedence over the globally
configured value.
Benefits of SSG AutoDomain

SSG AutoDomain provides the following benefits:
• Eliminates the need for users to be authenticated by SSG before connecting to a service. Users do
not have to be authenticated multiple times.
• Eliminates the need for service providers to make changes to existing AAA servers for virtual
private dialup network (VPDN) services.
• Provides an enhanced user experience.
• Provides subscribers with access to corporate virtual private networks (VPNs) based on APN alone.
• Enables users to access both simultaneous and sequential services without having to log off and log
back on to access different services.
• Supports overlapping host IP addresses.

To configure SSG subscriber authentication for services, perform the following tasks:
• Configuring SSG AutoDomain, page 127
• Monitoring and Maintaining SSG AutoDomain, page 129
• Troubleshooting SSG AutoDomain, page 130
Configuring SSG AutoDomain

Perform this task to configure the SSG AutoDomain feature.
SUMMARY STEPS
1. ssg auto-domain
2. mode extended
3. select {username | called-station-id calling-station-id | nas-identifier | attribute number}
4. exclude {apn | domain} name
5. download exclude-profile profile-name password
6. session-auto-terminate
7. nat user-address
8. end
9. Configure NAT in the service profile for the AutoDomain service.

78-17497-01 127
DETAILED STEPS

Step 1 ssg auto-domain Enables SSG AutoDomain and enters SSG-auto-domain
configuration mode.
Example:
Router(config)# ssg auto-domain
Step 2 mode extended (Optional) Selects extended AutoDomain.
Example:
Router(config-auto-domain)# mode extended
Step 3 select {username | called-station-id (Optional) Configures the AutoDomain selection method.
calling-station-id | nas-identifier | attribute
<number>} • username—Configures the algorithm to use only the
domain portion of the username to select the
AutoDomain.
Example:
Router(config-auto-domain)# select • called-station-id—Configures the algorithm to use
calling-station-id only the APN (Called-Station-ID).
• calling-station-id— Configures the algorithm to use
only the Calling Station ID.
• nas-identifier—Configures the algorithm to use only
the NAS-Identifier.
• attribute number—Configures any attribute to be
specified as the source for the AutoDomain name.
Specify the appropriate attribute number in the range
from 1 to 255. SSG does not limit the range of allowed
values.
By default, AutoDomain attempts to find a valid
AutoDomain based on APN (either Called-Station-ID or
NAS-Identifier) followed by the domain portion of the
username.
Step 4 exclude {apn | domain} name (Optional) Adds names to the AutoDomain exclusion list.
• apn—Adds an APN to the exclusion list.
Example: • domain—Adds a domain to the exclusion list.
Router(config-auto-domain)# exclude domain xyz
• name—Name of the APN or domain to be added to the
exclusion list.
Step 5 download exclude-profile profile-name password (Optional) Adds names to the AutoDomain download
exclusion list.
Example: • profile-name—Specifies the name for a list of excluded
Router(config-auto-domain)# download names that may be downloaded from the AAA server.
exclude-profile abc cisco
• password—Password for a list of excluded names that
may be downloaded from the AAA server.

128 78-17497-01

Step 6 session auto-terminate Terminates the session when the connection to the primary
auto-domain service terminates.
Example:
Router(config-auto-domain)# session
auto-terminate
Step 7 nat user-address (Optional) Configures NAT to be applied toward
AutoDomain services.
Example:
Router(config-auto-domain)# nat user-address
Example:
Router(config-auto-domain)# end
Step 9 Configure NAT in the service profile for the Defines a Service-Info attribute in the service profile for the
AutoDomain service. AutoDomain service.
Monitoring and Maintaining SSG AutoDomain

Perform this task to monitor and maintain SSG AutoDomain. The steps are all optional and may be
performed in any order.
SUMMARY STEPS
1. clear ssg radius-proxy client-address ip-address

2. clear ssg radius-proxy nas-address ip-address
3. show ssg auto-domain exclude-profile
4. show ssg binding
5. show ssg connection ip-address service-name
DETAILED STEPS

Step 1 clear ssg radius-proxy client-address ip-address (Optional) Clears all hosts connected to a specific
RADIUS client.
Router# clear ssg radius-proxy client-address
172.16.0.0
Step 2 clear ssg radius-proxy nas-address ip-address (Optional) Clears all hosts connected to a specific
Network Access Server (NAS).
Router# clear ssg radius-proxy nas-address
172.16.0.0

78-17497-01 129
Configuration Examples for SSG AutoDomain

Step 3 show ssg auto-domain exclude-profile (Optional) Displays the contents of an AutoDomain
exclusion profile downloaded from the AAA server.
Example: • Only AutoDomain exclude entries entered via
Router# show ssg auto-domain exclude-profile CLI are displayed.
Step 4 show ssg binding (Optional) Displays service names that have been
bound to interfaces and the interfaces to which they
have been bound.
Example:
Router# show ssg binding
Step 5 show ssg connection ip-address service-name (Optional) Displays the connections of a given host
and service name.
Example: • ip-address—IP address of an active SSG
Router# show ssg connection 19.1.1.19 InstMsg connection. This is always a subscribed host.
• service-name—The name of an active SSG
connection.
Troubleshooting SSG AutoDomain

Perform the tasks in this section to display port mapping event messages or port mapping packet
contents. The steps are all optional and may be performed in any order.
SUMMARY STEPS
1. debug ssg ctrl-events

2. debug ssg ctrl-errors
DETAILED STEPS

Step 1 debug ssg ctrl-events Displays SSG control event messages.
Example:
Router# debug ssg ctrl-events
Step 2 debug ssg ctrl-errors Displays SSG control error messages.
Example:
Router# debug ssg ctrl-errors
Configuration Examples for SSG AutoDomain

This section contains the following example:
• SSG AutoDomain: Example, page 131

130 78-17497-01
Where to Go Next
SSG AutoDomain: Example

In the following example, extended SSG AutoDomain is enabled. The default selection mode is
configured so that SSG attempts to select an AutoDomain based only on the username. An APN named
“excluded” and a domain named “cisco” are added to the AutoDomain exclusion list. An exclude-profile
named “abc” with a password “password1” is added to the AutoDomain download exclusion list. NAT
is applied toward AutoDomain services.
ssg enable
ssg auto-domain
mode extended
select username
exclude apn excluded
exclude domain cisco
download exclude-profile abc password1
nat user-address
Where to Go Next
To configure SSG to authenticate RADIUS Proxy subscribers, refer to Configuring SSG to Serve as a
RADIUS Proxy
The following sections provide references related to configuring SSG to authenticate subscribers for
services.
Related Documents
Release 12.4

78-17497-01 131
Feature Information for Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
Description Link
even more content.
Feature Information for Configuring SSG to Authenticate

Subscribers Automatically in the Service Domain
table.

132 78-17497-01
Table 3 Feature Information for Configuring SSG to Authenticate Subscribers Automatically in the Service Domain

SSG AutoDomain 12.2(4)B The SSG AutoDomain feature allows Service Selection
12.2(13)T Gateway (SSG) to authenticate subscribers automatically in
12.4 the service domain.
feature:
• Overview of SSG AutoDomain, page 122
• IP Address Assignment, page 123
• SSG AutoDomain Basic and Extended Modes,
page 124
• SSG AutoDomain Service Types, page 124
• Access Point Names, page 124
• AutoDomain Name Selection, page 125
• Multiple Local IP Pools, page 125
• Primary AutoDomain Service Termination, page 126
• SSG AutoDomain and NAT, page 126
• Benefits of SSG AutoDomain, page 127
• Configuring SSG AutoDomain, page 127
• Monitoring and Maintaining SSG AutoDomain,
page 129
• Troubleshooting SSG AutoDomain, page 130
• SSG AutoDomain: Example, page 131
exclude, mode extended, nat user-address, select, show
ssg auto-domain exclude-profile, ssg auto-domain

78-17497-01 133

134 78-17497-01
Configuring SSG for On-Demand IP Address
Renewal
The Configuring SSG for On-Demand IP Address Renewal feature enables service providers to manage
the Dynamic Host Configuration Protocol (DHCP) pool from which a subscriber’s IP address is
assigned. By receiving an IP address through DHCP rather than through Network Address Translation
(NAT), subscribers can access services that require a dynamically assigned IP address through the Cisco
Service Selection Gateway (SSG).
Module History

and configuration, use the Feature Information for SSG On-Demand IP Address Renewal, page 142.
Contents
• Prerequisites for SSG On-Demand IP Address Renewal, page 135
• Restrictions for SSG On-Demand IP Address Renewal, page 136
• Information About SSG On-Demand IP Address Renewal, page 136
• How to Configure SSG for On-Demand IP Address Renewal, page 138
• Configuration Examples for SSG On-Demand IP Address Renewal, page 140
Prerequisites for SSG On-Demand IP Address Renewal

• SSG must be enabled before on-demand IP address renewal can be configured.
• DHCP must be enabled on the router that is hosting SSG or on another router with SSG acting as a
DHCP relay agent.

78-17497-01 135
Configuring SSG for On-Demand IP Address Renewal
Restrictions for SSG On-Demand IP Address Renewal
Restrictions for SSG On-Demand IP Address Renewal

• Subscribers cannot connect to two or more services simultaneously when each service requires that
the subscriber’s IP address be assigned from a different pool.
Information About SSG On-Demand IP Address Renewal

To configure the SSG On-Demand IP Address Renewal feature, you should understand the following
concepts:
• Overview of SSG On-Demand IP Address Renewal, page 136
• DHCP Notification for SSG On-Demand IP Address Renewal, page 136
• Benefits of SSG On-Demand IP Address Renewal, page 138
Overview of SSG On-Demand IP Address Renewal

SSG implements Layer 3 service selection through selective routing of IP packets to destination
networks on a per-subscriber basis. It uses the subscriber’s IP address to identify the subscriber session.
A subscriber’s computer may have a static IP address or may request an IP address via DHCP or from a
RADIUS server. When the SSG On-Demand IP Address Renewal feature is not configured, SSG
performs network address translation (NAT) between the IP address assigned by the service provider
with the original IP address of the subscriber.
With the SSG On-Demand IP Address Renewal feature, you can configure SSG to force a subscriber to
request an IP address directly from a service provider. The IP address request process is described in the
“SSG On-Demand IP Address Renewal Packet Flow” section on page 137.
DHCP Notification for SSG On-Demand IP Address Renewal

Because the SSG On-Demand IP Address Renewal feature utilizes DHCP to provide a subscriber’s IP
address, the router on which SSG is running must either run the DHCP server feature, or act as a DHCP
relay agent.
The Cisco IOS DHCP Server feature is a full DHCP server implementation that assigns and manages IP
addresses from specified address pools within the router to DHCP clients.
A DHCP relay agent is any host that forwards DHCP packets between clients and servers. Relay agents
are used to forward requests and replies between clients and servers when they are not on the same
physical subnet. Relay agent forwarding is distinct from the normal forwarding of an IP router, where
IP datagrams are switched between networks somewhat transparently. Relay agents receive DHCP
messages and then generate a new DHCP message to send out on another interface.
The Cisco IOS DHCP relay agent supports the use of unnumbered interfaces. The DHCP relay agent
automatically adds a static host route specifying the unnumbered interface as the outbound interface.
For optimal performance, Cisco recommends that the router running SSG also function as a DHCP relay
agent, with the DHCP server running on a separate platform.
For more details about configuring DHCP, see the “Configuring DHCP” chapter in Part 1 of the
Cisco IOS IP Configuration Guide, Release 12.3, and the DHCP Enhancements for Edge-Session
Management feature module for Cisco IOS Release 12.3(14)T.

136 78-17497-01
Information About SSG On-Demand IP Address Renewal
SSG On-Demand IP Address Renewal Packet Flow

Figure 9 is a diagram of a simple network topology that supports on-demand IP address renewal for SSG.
In this sample configuration, the router running SSG also acts as the DHCP relay agent, whereas the
DHCP server is running on a separate platform.
Figure 9 Simple On-Demand IP Address Renewal Network Topology
127931
Subscriber's PC SSG DHCP server
DHCP module
In on-demand IP address renewal, the following events occur:

1. On bootup, a subscriber’s computer sends a DHCPDISCOVER request to the DHCP relay agent.
The DHCP relay agent forwards the DHCPDISCOVER request to the DHCP server.
2. The DHCP server assigns the subscriber a short lease-time IP address from the private address pool
in a DHCPOFFER response, which is passed through SSG to the subscriber.
3. The subscriber’s computer sends a DHCPREQUEST to the DHCP server, which responds with a
DHCPACK to acknowledge receipt of the request and start the lease.
4. The DHCP relay agent informs SSG about this event by invoking the
reg_invoke_dhcpd_address_assignment_notify() registry call. Since there is not yet a host object for
the subscriber, SSG ignores this event. If transparent autologon (TAL) is enabled, however, SSG will
trigger TAL for this IP address. The TAL authorization request will contain the MAC address of the
user in RADIUS attribute 31.
5. Upon receipt of DHCPACK, the subscriber can log into his or her account and service. When the
subscriber logs into a service for which an ISP-supplied IP address is mandated in the service
profile, SSG triggers the DHCP relay agent to terminate the current lease and force the subscriber’s
computer to rediscover an IP address.
6. The subscriber’s computer sends a new DHCPREQUEST to the DHCP relay agent.
7. The DHCP relay agent replies with a DHCPNAK message, forcing the subscriber’s computer to send
a new DHCPDISCOVER message.
8. Upon receipt of the new DHCPDISCOVER request, the DHCP relay agent informs SSG, which
replies with the class name of the service.
9. The DHCP relay agent then forwards the DHCPDISCOVER request and class name to the DHCP
server.
10. The DHCP server assigns an IP address from the service provider’s address pool and sends a
DHCPOFFER message to the subscriber’s computer. The subscriber’s computer replies with a
DHCPREQUEST message, passed transparently through SSG.
11. The DHCP server sends a DHCPAK containing an IP address from the service provider’s address
pool. This IP address will have a finite lease time, typically a few minutes.
12. The DHCP relay agent informs SSG about the IP address assignment. SSG creates a host object for
this new IP address and sends an Accounting-Start packet. SSG then removes the host object initially
created for the IP address assigned from the private address pool (Step 2) and sends an
Accounting-Stop packet.
13. When finished using the service, the subscriber may disconnect in one of two ways:

78-17497-01 137
How to Configure SSG for On-Demand IP Address Renewal
a. By logging out of the service. SSG informs the DHCP relay agent, which begins the process to
forces the subscriber’s computer to rediscover an IP address in the private address pool.
b. By sending a DHCPRELEASE message (for instance, if the subscriber shuts down his or her
computer). The DHCP relay agent informs SSG, which removes the host object of this
subscriber.
Benefits of SSG On-Demand IP Address Renewal

The principal benefit of the SSG On-Demand IP Address Renewal feature is to allow service providers
to manage subscriber access to services using SSG while retaining the ability to assign an IP address
from a pool configured for a specific service.
For Ethernet access subscribers, service providers can provide a short-term lease of an IPv4 address, and
then, after authentication, provide a new IP address through DHCP. This two-stage IP address allocation
process allows a service provider to reduce the number of assigned IPv4 addresses.

• Configuring SSG On-Demand IP Address Renewal, page 138 (required)
• Verifying and Troubleshooting SSG On-Demand IP Address Renewal, page 139 (optional)
Configuring SSG On-Demand IP Address Renewal

This task explains how to configure SSG for on-demand IP address renewal.
SUMMARY STEPS
1. enable
3. ssg intercept dhcp

138 78-17497-01
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ssg intercept dhcp Configures SSG to force a subscriber’s computer, upon
logging into an ISP service, to request an IP address from
the DHCP pool associated with the service profile.
Example:
Router<config># ssg intercept dhcp
Verifying and Troubleshooting SSG On-Demand IP Address Renewal

The following tasks display configuration and event information when SSG on-demand IP address
renewal is enabled:
• Verifying a Subscriber’s IP Address, page 139
• Displaying Subscriber Login Events and Errors for the SSG On-Demand IP Address Renewal
Feature, page 140
Verifying a Subscriber’s IP Address

Perform this task to verify a subscriber’s IP address.
SUMMARY STEPS
1. enable
2. show ssg host [ip-address | count | username]
DETAILED STEPS
Step 1 enable
Enables privileged EXEC mode. Enter your password if prompted.
Router> enable
Step 2 show ssg host [ip-address | count | username]

Use this command with the username keyword to display all host usernames and IP addresses. Use this
command with the subscriber’s IP address as the ip-address argument to display information about an
individual subscriber.
Router# show ssg host username

78-17497-01 139
Configuration Examples for SSG On-Demand IP Address Renewal
1:10.3.1.1 (active) Host name:pppoauser

2:10.3.6.1 (active) Host name:ssguser2
### Total HostObject Count(including inactive hosts):2
Displaying Subscriber Login Events and Errors for the SSG On-Demand IP Address Renewal Feature
Perform this task to display subscriber login events and errors when the SSG On-Demand IP Address
Renewal feature is enabled.
SUMMARY STEPS
1. enable
2. debug ssg dhcp {error | event} [ip_address]
DETAILED STEPS
Step 1 enable
Router> enable
Step 2 debug ssg dhcp {error | event} [ip_address]

To limit the display of information to a specific subscriber, enter the subscriber’s IP address as the
ip-address argument. Use the error keyword to display only error messages, or the event keyword to
display only event messages.
Router# debug ssg dhcp event 1.1.1.5
SSG DHCP awareness events debugging is on
2d20h: SSG-DHCP-EVN: DHCP-DISCOVER event received. SSG-dhcp awareness feature enabled

2d20h: SSG-DHCP-EVN:1.1.1.5: Get pool name called for 000c.31ea.a9c0
2d20h: SSG-DHCP-EVN: Get pool class called, class name = ISP_svc1
### Total HostObject Count(including inactive hosts):2
Configuration Examples for SSG On-Demand IP Address

Renewal
This section contains the following example:
• Configuring SSG for On-Demand IP Address Renewal: Example, page 141

140 78-17497-01
Configuring SSG for On-Demand IP Address Renewal: Example

The following example shows a simple configuration to enable SSG to support on-demand IP address
renewal.
enable
configure terminal
ssg intercept dhcp
The following sections provide references related to the SSG On-Demand IP Address Renewal feature.
Related Documents
Configuring DHCP “DHCP” section of the Cisco IOS IP Addressing Services
DHCP Lease Query Support DHCP Enhancements for Edge-Session Management feature
module for Cisco IOS Release 12.3(14)T
Release 12.4
Description Link
Cisco.com users can log in from this page to access
even more content.

78-17497-01 141
Glossary
Glossary
DHCP—Dynamic Host Configuration Protocol.
DHCP relay agent—Any host that forwards DHCP packets between clients and servers.
DHCP server—An application that assigns and manages IP addresses from specified address pools
within the router to DHCP clients.
SSG—Service Selection Gateway.
subscriber—The end user who accesses a service provided by a service provider via SSG.
Note See Internetworking Terms and Acronyms for terms not included in this glossary.
Feature Information for SSG On-Demand IP Address Renewal

features that were introduced or modified in Cisco IOS Release 12.3(14)T or a later release appear in the
table.

142 78-17497-01
Table 4 Feature Information for SSG On-Demand IP Address Renewal

On-Demand IP Address Renewal for SSG 12.3(14)T The SSG On-Demand IP Address Renewal feature enables
12.4 service providers to manage the Dynamic Host
Configuration Protocol (DHCP) pool from which a
subscriber’s IP address is assigned.
feature:
• Overview of SSG On-Demand IP Address Renewal,
page 136
• DHCP Notification for SSG On-Demand IP Address
Renewal, page 136
• SSG On-Demand IP Address Renewal Packet Flow,
page 137
• Benefits of SSG On-Demand IP Address Renewal,
page 138
• Configuring SSG On-Demand IP Address Renewal,
page 138
• Verifying and Troubleshooting SSG On-Demand IP
Address Renewal, page 139
• Configuring SSG for On-Demand IP Address Renewal:
Example, page 141
The following commands were introduced or modified by
this feature: debug ssg dhcp, ssg intercept dhcp.

78-17497-01 143

144 78-17497-01
Configuring SSG Support for Subnet-Based
Authentication
The SSG Support for Subnet-Based Authentication feature allows a service provider to identify
subscribers to services by their subnet, rather than by a subscriber’s IP address. This module describes
how the Cisco Service Selection Gateway (SSG) recognizes and manages subnet-based subscribers.
Module History

and configuration, use the “Feature Information for SSG Support for Subnet-Based Authentication”
section on page 148.
Contents
• Prerequisites for SSG Support for Subnet-Based Authentication, page 145
• Restrictions for SSG Support for Subnet-Based Authentication, page 145
• Information About SSG Support for Subnet-Based Authentication, page 146
• How to Configure SSG Support for Subnet-Based Authentication, page 146
Prerequisites for SSG Support for Subnet-Based Authentication

SSG must be enabled before subnet-based authentication for SSG can be configured.
Restrictions for SSG Support for Subnet-Based Authentication

• If the Port-Bundle Host Key (PBHK) feature is used with subscribers, the port bundle allocated to a
subscriber will be shared for all IP addresses within the IP subnet.
• RADIUS proxy deployments do not support subnet-based subscribers.

78-17497-01 145
Configuring SSG Support for Subnet-Based Authentication
Information About SSG Support for Subnet-Based Authentication
• Subnet-based authentication is not supported for users with PPP-based access.

• Once a subscriber is identified as a subnet-based subscriber, all other individual subscribers on the
same subnet will be tracked as part of the same subnet subscriber.
• Services that require Network Address Translation (NAT) are not supported.
Information About SSG Support for Subnet-Based

Authentication
To configure the SSG Support for Subnet-Based Authentication feature, you should understand the
following concepts:
• Identifying Subnet-Based Subscribers, page 146
• Benefits of SSG Support for Subnet-Based Authentication, page 146
Identifying Subnet-Based Subscribers

Subnet-based subscribers are identified whenever SSG receives a subnet mask along with an IP address
from the authentication, authorization, and accounting (AAA) server. The IP address is found in the
RADIUS Framed-IP (FIP) attribute (RADIUS attribute 8), and the IP subnet mask is found in the
RADIUS-Framed-IP-Netmask (FIN) attribute (RADIUS attribute 9).
Benefits of SSG Support for Subnet-Based Authentication

Subnet-based authentication of subscribers gives service providers the option to provide services to their
enterprise customers based on the IP subnet rather than on an individual IP address. This capability
eliminates the need for each subscriber to self-identify and log in. Applications of subnet-based
authentication include business internet services, video streaming, and pay-per-use Internet access for
small office/home office (SOHO) customers.
How to Configure SSG Support for Subnet-Based Authentication

No configuration is required to identify subnet-based subscribers. Whenever SSG receives a subscriber’s
IP address and subnet mask from the AAA (RADIUS) server, SSG will treat that subscriber as a
subnet-based subscriber.
This section contains the following task:
• Verifying SSG Support for Subnet-Based Authentication, page 146 (optional)
Verifying SSG Support for Subnet-Based Authentication

This optional task explains how to verify subnet-based authentication for SSG. The commands contained
in the task steps can be used in any sequence and may need to be repeated.

146 78-17497-01
How to Configure SSG Support for Subnet-Based Authentication
SUMMARY STEPS
1. enable
2. show ssg connection {ip-address | network-id subnet-mask} service-name [interface]
3. show ssg host [ip-address | count | username] [interface [username] [subnet-mask]]
DETAILED STEPS
Step 1 enable
Router> enable
Step 2 show ssg connection {ip-address | network-id subnet-mask} service-name [interface]

Displays the connections of a given SSG host and service name. To display the connections of the
specified subnet-based subscribed host, enter the network ID and IP subnet mask.
Router# show ssg connection 10.0.1.1 255.255.255.0 passthru
------------------------ConnectionObject Content -----------------------

User Name: dev-user2
Owner Host: 10.0.1.1 (Mask : 255.255.255.0)
Associated Service: passthru1
Calling station id: 00d0.792f.8054
Connection State: 0 (UP)
Connection Started since: *17:44:59.000 GMT Sun Jul 6 2004
User last activity at: *17:44:59.000 GMT Sun Jul 6 2004
Connection Traffic Statistics:
Input Bytes = 0, Input packets = 0
Output Bytes = 0, Output packets = 0
Step 3 show ssg host [ip-address | count | username] [interface [username] [subnet-mask]]
Displays information about a subscriber and the subscriber’s current connections. To display information
about the specified subnet-based subscribed host, enter the IP subnet mask.
Router# show ssg host 10.0.0.0 255.255.255.0

Activated: TRUE
Interface:
User Name: user1
Host IP : 10.0.0.0
Mask : 255.255.255.0
Msg IP: 0.0.0.0 (0)
Class Attr: NONE
SMTP Forwarding: NO
Active Services: NONE
AutoService: NONE

78-17497-01 147
Subscribed Services: passthru1; proxynat1; tunnel1; proxy1

The following sections provide references related to the SSG Support for Subnet-Based Authentication
feature.
Related Documents
Release 12.4
Description Link
even more content.
Feature Information for SSG Support for Subnet-Based

Authentication
table.

148 78-17497-01
Feature Information for SSG Support for Subnet-Based Authentication
Table 5 Feature Information for SSG Support for Subnet-Based Authentication

SSG Support for Subnet-Based Authentication 12.3(14)T The SSG Support for Subnet-Based Authentication feature
12.4 allows a service provider to identify subscribers to services
by their subnet, rather than by a subscriber’s IP address.
feature:
• Identifying Subnet-Based Subscribers, page 146
• Benefits of SSG Support for Subnet-Based
Authentication, page 146
• Verifying SSG Support for Subnet-Based
Authentication, page 146
The following commands were modified by this feature:
show ssg connection, show ssg host.

78-17497-01 149
Feature Information for SSG Support for Subnet-Based Authentication

150 78-17497-01
Configuring SSG for MAC-Address-Based
Authentication
The MAC-Address-Based Authentication for SSG feature allows a service provider to authorize
subscriber access to services by the subscriber’s MAC address, thus eliminating the need for explicit user
logins between client power cycles. This module describes how the Cisco Service Selection Gateway
(SSG) recognizes and manages MAC-address-based subscribers.
Module History

and configuration, use the “Feature Information for Configuring SSG for MAC-Address-Based
Authentication” section on page 159.
Contents
• Prerequisites for MAC-Address-Based Authentication for SSG, page 151
• Restrictions for MAC-Address-Based Authentication for SSG, page 152
• Information About MAC-Address-Based Authentication for SSG, page 152
• How to Configure MAC-Address-Based Authentication for SSG, page 156
Prerequisites for MAC-Address-Based Authentication for SSG

• SSG must be enabled before MAC-address-based authentication for SSG can be configured.
• The SSG Transparent Autologon (TAL) feature must be configured.
• Dynamic Host Configuration Protocol (DHCP) lease query functionality is required when the
subscriber’s MAC address is not available in the Address Resolution Protocol (ARP) table, or when
the DHCP call flows between the subscriber and the DHCP server bypass the SSG.

78-17497-01 151
Configuring SSG for MAC-Address-Based Authentication
Restrictions for MAC-Address-Based Authentication for SSG
Restrictions for MAC-Address-Based Authentication for SSG

Because subscribers can share a MAC address (for instance, users of the same computer), the activity of
an individual subscriber cannot be tracked when the MAC address is used to authorize access to services.
Information About MAC-Address-Based Authentication for SSG

To configure the MAC-Address-Based Authentication for SSG feature, you should understand the
following concepts:
• Overview of MAC-Address-Based Authentication for SSG, page 152
• Subscriber Login with MAC-Address-Based Authentication for SSG, page 152
• Benefits of MAC-Address-Based Authentication for SSG, page 156
Overview of MAC-Address-Based Authentication for SSG

The MAC-Address-Based Authentication for SSG feature gives service providers the option to
authenticate subscribers on the basis of their MAC address rather than their IP address.
When a subscriber first logs in through the explicit login process, a subscriber profile containing the
subscriber’s MAC address is created by the authentication, authorization, and accounting (AAA) and
Lightweight Directory Access Protocol (LDAP) applications and is stored on the LDAP server.
Subsequent logins will be authorized through the implicit login process because the AAA and LDAP
servers authenticate the subscriber in response to the access request from SSG, which contains the
subscriber’s MAC address. Because a previously authenticated subscriber need not self-identify and log
in to previously authorized services, a service provider can offer an “always-on” service.
MAC Address as Username for Transparent Autologon

By default, the TAL feature identifies subscribers by their IP addresses. When MAC-address-based
authentication is configured, service providers can use a subscriber’s MAC address instead.
SSG obtains a subscriber’s MAC address from a DHCP server by sending a DHCP lease query request
containing the subscriber’s IP address. This process is explained in further detail in the “Explicit Login
Call Flow” section on page 153. Once a subscriber’s MAC address has been authenticated, the subscriber
can gain access to services through transparent autologon. This process is explained in further detail in
the “Implicit Login Call Flow” section on page 155.
Subscriber Login with MAC-Address-Based Authentication for SSG

The first time a subscriber attempts to access the service provider network, SSG redirects the
subscriber’s HTTP session to the Cisco Subscriber Edge Services Manager (SESM), which then prompts
the subscriber for a username and password. This process is called explicit login. During the explicit
login process, SSG acquires and authorizes the subscriber’s MAC address. When the subscriber logs off
and logs in again, the session will be created through TAL, since the subscriber’s MAC address is already
known and authenticated. This process is called implicit login.

152 78-17497-01
Figure 10 is a diagram of of the network topology when the MAC-Address-Based Authentication for
SSG feature is enabled. In this sample configuration, the router running SSG also acts as the DHCP relay
agent, while the DHCP server, SESM, AAA, and Lightweight Directory Access Protocol (LDAP)
services run on separate platforms.
Figure 10 MAC-Address-Based Authentication for SSG Network Topology
Subscriber's PC SSG DHCP SESM AAA LDAP

L3 switch
server (NWSP) server
127932
DHCP relay agent
(CNR) (RDP)
Explicit Login Call Flow

In the explicit login process, the following events occur:
1. On bootup, a subscriber’s computer sends a DHCPDISCOVER request packet to the DHCP relay
agent. The DHCP relay agent forwards the DHCPDISCOVER request packet to the DHCP server.
2. The DHCP server assigns the subscriber an IP address from the private address pool in a
DHCPOFFER response packet, which is passed through SSG to the subscriber.
3. The subscriber’s computer sends a DHCPREQUEST packet to the DHCP server.
4. The DHCP server acknowledges the subscriber’s IP assignment by returning a DHCPACK packet.
5. SSG receives an HTTP IP packet from the subscriber and sends a DHCP lease query request packet,
based on the subscriber’s IP and Virtual Private Network (VPN) information, before attempting a
TAL request. The DHCP relay agent sends the DHCP lease query request packet to all that were
servers configured using the ip dhcp-server command. If no DHCP servers are configured, the
DHCP lease query request packet will be broadcast on all interfaces.
6. SSG receives the subscriber’s MAC address in the the DHCP lease query response packet from the
DHCP server that has assigned the IP address to the subscriber.
7. SSG sends a TAL Authorization-Request packet to the AAA server. The TAL authorization request
packet contains the following attributes relevant to the MAC-Address-Based Authentication for SSG
feature:
– User-Name (attribute 1): The subscriber’s IP address, in dotted decimal notation.
– Password (attribute 2): The global service password configured on SSG.
– Calling-station-id (attribute 31): The subscriber’s MAC address. Note that this attribute will be
present only when SSG receives a valid MAC address in the DHCP lease query response packet.
– Framed-ip (attribute 8): The subscriber’s IP address.
– Service-type (attribute 6): “outbound” (value 5).
8. The AAA server sends a query based on the subscriber’s MAC address to the LDAP application.
9. The LDAP application sends a “no entry” response.
10. The AAA server sends an Access-Reject packet to SSG.
11. SSG redirects the subscriber’s HTTP session to SESM.

78-17497-01 153
12. SESM presents an accounting logon page to the subscriber, asking for the username and password.
The subscriber enters this information and clicks the “logon” button.
13. SESM sends an Account-Logon request packet containing the subscriber’s username and password
to SSG.
14. SSG sends a DHCP lease query request packet for the subscriber to the DHCP server and sends an
authentication request packet to the AAA server. If no DHCP servers have been configured using
the ip dhcp-server command, the DHCP lease query request packet is broadcast on all interfaces.
15. The DHCP server returns the subscriber’s MAC address to SSG.
16. SSG sends an Access-Request packet to the AAA server to authenticate the subscriber. Along with
other attributes, the Access-Request packet includes the following:
– User-Name(attribute 1): The username entered by the subscriber on the SESM accounting logon
page.
– Password (attribute 2): The password entered by the subscriber on the SESM accounting logon
page.
17. The AAA server sends a query to the LDAP application to verify the subscriber’s username.
18. The LDAP application finds an entry for the subscriber and sends the subscriber’s profile to the
AAA server.
19. The AAA server sends an Access-Accept packet to SSG.
20. SSG creates a host object for the subscriber based on the contents of the Access-Accept packet and
forwards the access-accept packet to SESM. Along with other attributes, the Access-Accept packet
includes the following:
21. SESM adds the subscriber’s MAC address to the subscriber’s record.
22. SSG sends an Accounting-Start packet to the AAA server. Along with other attributes, the
Accounting-Start packet includes the following:
– Username (attribute 1): The username of the subscriber as received in the Access-Accept
packet.
23. The AAA server sends an Accounting-Response packet to SSG.
24. When the subscriber logs out, SSG deletes the host object for that subscriber.

154 78-17497-01
Implicit Login Call Flow

When a subscriber has logged in once through the explicit login call flow, subsequent logins proceed
more quickly. The subscriber is not required to re-enter login information, because the subscriber’s MAC
address is already known and authenticated. In the implicit login process, the following events occur:
1. On bootup, a subscriber’s computer sends a DHCPDISCOVER request packet to the DHCP relay
agent. The DHCP relay agent forwards the DHCPDISCOVER request packet to the DHCP server.
2. The DHCP server assigns the subscriber an IP address from the private address pool in a
DHCPOFFER response packet, which is passed through SSG to the subscriber.
3. The subscriber’s computer sends a DHCPREQUEST packet to the DHCP server.
4. The DHCP server acknowledges the subscriber’s IP assignment by returning a DHCPACK packet.
5. SSG receives an HTTP IP packet from the subscriber and sends a DHCP lease query packet request,
based on the subscriber’s IP and VPN information, before attempting a transparent autologon (TAL)
request. The DHCP relay agent sends the DHCP lease query request packet to all servers that were
configured using the ip dhcp-server command. If no DHCP servers are configured, the DHCP lease
query request packet will be broadcast on all interfaces.
6. SSG receives the MAC address for the provided IP address in the DHCP lease query response packet
from the DHCP server that has assigned the IP address to the subscriber.
7. SSG sends a TAL authorization request packet to the AAA server. The TAL Authorization-Request
packet contains the following attributes relevant to the MAC-Address-Based Authentication for SSG
feature:
– User-Name (attribute 1): The subscriber’s IP address, in dotted decimal notation.
– Password (attribute 2): The global service password configured on SSG.
– Service-type (attribute 6): “outbound” (value 5).
8. The AAA server sends a query based on the subscriber’s MAC address to the LDAP server.
9. The LDAP application finds the profile for the subscriber’s MAC address and sends this profile to
the AAA server.
10. The AAA server sends the subscriber profile in an Access-Accept packet to SSG. SSG creates a host
object for the subscriber based on the contents of the Access-Accept packet and forwards the
Access-Accept packet to SESM. Along with other attributes, the Access-Accept packet includes the
following:
11. SSG sends an Accounting-Start packet to the AAA server. Along with other attributes, the
Accounting-Start packet includes the following:
– Username (attribute 1): The username of the subscriber as received in the Access-Accept
packet.

78-17497-01 155
How to Configure MAC-Address-Based Authentication for SSG
12. The AAA server sends an Accounting-Response packet to SSG.

13. When the subscriber logs out, SSG deletes the host object for that subscriber.
Benefits of MAC-Address-Based Authentication for SSG

The MAC-Address-Based Authentication for SSG feature allows service providers to offer subscribers
an “always on” experience when accessing services for which the subscriber has already been
authenticated.

• Configuring a DHCP Lease Query Request for MAC-Address-Based Authentication, page 156
(required)
• Configuring an IP DHCP Lease Query Request, page 157 (optional)
Configuring a DHCP Lease Query Request for MAC-Address-Based

Authentication
This task explains how to configure a DHCP lease query request for MAC-address-based authentication
for SSG.
SUMMARY STEPS
1. enable
3. ssg query mac dhcp
4. username mac
DETAILED STEPS

Example:
Router> enable
Example:

156 78-17497-01

Step 3 ssg query mac dhcp Enables SSG to send a DHCP lease query request to
determine the subscriber’s MAC address.
Example:
Router(config)# ssg query mac dhcp
Step 4 username mac Configures SSG to send a subscriber’s MAC address as the
username in TAL authorization requests.
Example:
Router(config)# username mac
Configuring an IP DHCP Lease Query Request

This task explains how to configure a DHCP lease query request for MAC-address-based authentication
for SSG when no IP address is received in the accounting-start record.
SUMMARY STEPS
1. enable
3. ssg radius-proxy
4. client-address ip-address [vrf vrf-name]
5. query ip dhcp
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ssg radius-proxy Enables the SSG RADIUS proxy.
Example:
Router(config)# ssg radius proxy

78-17497-01 157
Configuration Examples for SSG MAC-Address-Based Authentication

Step 4 client-address ip-address [vrf vrf-name] Configures the RADIUS client to proxy requests from a
specified IP address to a RADIUS server.
Example:
Router(config-radius-proxy)# client-address
10.0.0.0
Step 5 query ip dhcp Enables DHCP lease query requests for a RADIUS proxy
client.
Example:
Router(config-radproxy-client)# query ip dhcp
Configuration Examples for SSG MAC-Address-Based

Authentication
This section contains the following configuration examples:
• Configuring SSG for MAC-Address-Based Authentication: Example, page 158
• Configuring an IP DHCP Lease Query Request: Example, page 158
Configuring SSG for MAC-Address-Based Authentication: Example

The following example shows a simple configuration to enable SSG to support MAC-address-based
authentication:
enable
configure terminal
ssg query mac dhcp
username mac
Configuring an IP DHCP Lease Query Request: Example

The following example shows a simple configuration to configure a DHCP lease query request for
MAC-address-based authentication for SSG when no IP address is received in the accounting-start
record:
enable
configure terminal
ssg radius-proxy
query ip dhcp

158 78-17497-01
The following sections provide references related to the MAC-Address-Based Authentication for SSG
feature.
Related Documents
Configuring DHCP “DHCP” section in the Cisco IOS IP Addressing and Services
DHCP Lease Query Support DHCP Enhancement for Edge-Session Management, feature module
for Cisco IOS Release 12.3(14)T.
Release 12.4
Description Link
even more content.
Feature Information for Configuring SSG for

MAC-Address-Based Authentication
table.

78-17497-01 159
Feature Information for Configuring SSG for MAC-Address-Based Authentication
Table 6 Feature Information for SSG On-Demand IP Address Renewal

MAC-Addressed-Based Authentication for SSG 12.3(14)T The MAC-Address-Based Authentication for SSG feature
12.4 allows a service provider to authorize subscriber access to
services by the subscriber’s MAC address, thus eliminating
the need for explicit user logins between client power
cycles.
feature:
• Overview of MAC-Address-Based Authentication for
SSG, page 152
• Subscriber Login with MAC-Address-Based
Authentication for SSG, page 152
• Benefits of MAC-Address-Based Authentication for
SSG, page 156
• Configuring a DHCP Lease Query Request for
MAC-Address-Based Authentication, page 156
• Configuring an IP DHCP Lease Query Request,
page 157
• Configuring SSG for MAC-Address-Based
Authentication: Example, page 158
• Configuring an IP DHCP Lease Query Request:
Example, page 158
query ip dhcp, ssg query mac dhcp, username mac.

160 78-17497-01
Configuring SSG for Subscriber Services
The Cisco Service Selection Gateway (SSG) is deployed at network aggregation points to control
subscriber access to network services. SSG can be configured to support authenticated pass-through,
proxy, and Layer 2 Tunnel Protocol (L2TP) services, as well as unauthenticated open garden services.
This module provides information about how to configure SSG to create services and allow subscribers
to use them.
Module History

and configuration, use the “Feature Information for SSG Subscriber Services” section on page 203.
Contents
• Prerequisites for Configuring SSG for Subscriber Services, page 161
• Information About SSG Support for Subscriber Services, page 162
• How to Configure Services for Subscribers, page 170
• Configuration Examples for SSG Support for Subscriber Services, page 191
Prerequisites for Configuring SSG for Subscriber Services

Before you can perform the tasks in this process, SSG must be enabled.
Service profiles must be configured in the authentication, authorization, and accounting (AAA) server.
See the RADIUS Profiles and Attributes for SSG module for information about RADIUS profiles and
vendor-specific attributes (VSAs) for SSG.
SSG, Cisco Subscriber Edge Services Manager (SESM), and AAA must be configured correctly in order
for subscribers to be able to access services.

78-17497-01 161
Information About SSG Support for Subscriber Services

Before you configure SSG support for services, you should understand the following concepts:
• Services and Service Profiles, page 162
• Authenticated Services, page 162
• How SSG Routes to Services, page 164
• Open Garden (Unauthenticated) Services, page 165
• SSG Uplink Interface Redundancy and Load Balancing, page 166
• DNS Packet Handling, page 169
• SSG Transparent Pass-Through, page 169
• Service Profile Caching, page 170
Services and Service Profiles

A service is a type of network access, either access to paid applications or access to free applications.
Services are defined by attributes.
A service profile is a collection of attributes that defines a service. Service profiles include information
such as the following: type of service (pass-through, proxy, or L2TP), service access mode (sequential
or concurrent), Domain Name System (DNS) server IP address for the service, networks that exist in the
service domain, access control lists, and timeouts.
Service providers can use attributes to define a wide range of subscriber services, such as a particular
level of quality of service, tunneling, personal firewalls and traffic filters, dynamic bandwidth change,
free access or paid access, and service selection.
RADIUS service profiles can be configured on the following devices:
• The AAA server—when SESM is working in RADIUS mode
• The Lightweight Directory Access Protocol (LDAP) server—when SESM is working in LDAP
mode
• Directly on SSG—generally used for open garden services and for testing purposes
SSG and SESM download service profiles from the AAA server or LDAP server as needed.
Authenticated Services
Authenticated services are services that a subscriber can access after providing valid authentication
information. There are five types of authenticated services, which are described in the following
sections:
• Pass-Through Services, page 163
• Proxy Services, page 163
• L2TP Dial-In Services, page 163
• L2TP Dial-Out Services, page 164
• DNS Packet Handling, page 164

162 78-17497-01
Pass-Through Services
SSG does not authenticate users specifically for pass-through services. One example in which a
pass-through service may be used is when a Network Access Provider (NAP) provides Internet service.
After authenticating the user, the NAP does not require another authentication to provide the user with
Internet service.
If the IP address pool name VSA is configured in the service profile for a pass-through service, SSG will
choose one IP address from the pool as the service IP address and perform NAT between the user’s actual
IP address and the IP address of the service.
Proxy Services
Proxy services involve subscriber authentication for the service, such as when a NAP partners with an
Internet Service Provider (ISP) to provide Internet service, or with a content provider to provide content.
In these cases, the NAP authenticates the user, but before the user can access the service provided by the
partner, the partner also authenticates the user (service-level authentication).
When a subscriber requests access to a proxy service, SESM prompts the user for the username and
password. SSG then performs the service authentication by sending an Access-Request packet to the
remote AAA server configured in the service profile. Upon receiving an Access-Accept packet from the
remote RADIUS server, SSG logs the subscriber in to the service. SSG must be configured as a network
access server (NAS) client on the remote RADIUS server.
The service IP address can be chosen by one of the following methods (ordered according to priority, the
highest first):
1. The remote AAA server sends the Framed-IP-address attribute (RADIUS attribute 8) in the
Access-Accept packet.
2. The remote AAA server provides the IP address pool name VSA in the Access-Accept packet. In
this case, SSG chooses one IP address from the locally configured pool as the service IP address.
3. The IP address pool name VSA may be configured in the service profile. In this case, SSG chooses
one IP address from the service pool as the service IP address.
SSG supports both Password Authentication Protocol (PAP) and Challenge Handshake Authentication
Protocol (CHAP) authentication for proxy services.
L2TP Dial-In Services

SSG can be used to provide L2TP dial-in services to access corporate networks. In this case, SSG serves
as an L2TP access concentrator (LAC) and initiates an L2TP tunnel to the corporate L2TP network
server (LNS).
For every user, SSG creates a PPP session through the tunnel to the remote LNS. For the L2TP or PPP
session authentication, SESM prompts the user for a username and password. NAT is always performed
between subscriber IP address and the LNS-assigned IP address.
Note Effective with Cisco IOS Release 12.2(16)B, SSG passes the mobile station ID (MSID) of the user, if
present, to the LNS in the Calling Number attribute value (AV) pair (22) of the Incoming-Call-Request
(ICRQ) control message during L2TP session establishment. If LNS is using RADIUS authentication,
the MSID value will also be copied to the Calling-Station-ID attribute (31), of the subsequently
generated Access-Request packet.

78-17497-01 163
For more information about SSG support for L2TP tunnel services, see the “What to Do Next” section
on page 172.
L2TP Dial-Out Services

SSG L2TP dial-out services provide mobile users with a way to securely connect to their small
office/home office (SOHO) corporate networks through the public switched telephone network (PSTN).
In this case, SSG serves as an LNS that creates a dial-out tunnel to the LAC, which in turn dials into the
corporate gateway.
To provide L2TP dial-out services, SSG requires a digital number identification service (DNIS) number
for the dial-up corporate gateway to which the user wants to connect, the address of the LAC closest to
the SOHO, and configured tunnel parameters to establish a tunnel to the LAC.
For more details about SSG support for L2TP dial-out services, see the “Configuring SSG to Support
L2TP Dial-Out Services” section on page 177.
DNS Packet Handling

When SSG receives DNS requests, the DNS packets are first processed for the user connection. If the
domain match is not found, the packets are processed for open gardens.
In the upstream direction, SSG handles DNS packets by first looking up the domain in the
connected-service list. If a match is not found in the connected-service list, the open garden service list
is checked. If the domain is not found in the open garden service list and the user has a connected Internet
service (0.0.0.0/0), the DNS request is forwarded to that domain. If the user is not connected to an
Internet service and there is an open garden Internet service, the DNS request is forwarded to the open
garden Internet domain.
In the downstream direction, SSG handles DNS response packets in the same order in which they are
handled in the upstream direction.
Note DNS packet processing in an open garden configuration was handled differently by SSG in Cisco IOS
Release 12.2(2)B and earlier releases. In those releases, DNS domain lookup was performed first in
the domains configured in the open garden services. If a match was not found, DNS domain lookup
was performed in the connected services of the user.
If SSG receives a packet that is not destined for the open garden, SSG checks the source IP address of
the packet to see if the subscriber is authenticated. If SSG recognizes the IP address, the subscriber is
authenticated and SSG forwards the packet. If the subscriber is not authenticated and the packet is not a
DNS packet, SSG drops the packet.
How SSG Routes to Services

By default, packets going from a user to a service are not routed by SSG using the global IP routing table.
In order for SSG to route packets destined for services, all services (except L2TP tunnel services) must
be bound to either an interface or a next hop.
When a service is bound to a next hop, SSG sends all traffic destined to the service to the next hop. This
functionality is similar to setting the next hop using Policy Based Routing (PBR). For example, in an
equal access network (EAN) environment in which multiple ISPs are providing Internet connectivity,
SSG will send traffic to the gateway (next hop) of the appropriate ISP.

164 78-17497-01
When a service is bound to a point-to-point interface, SSG sends the traffic on that interface. If a service
is bound to an interface that is not point-to-point (such as Ethernet), SSG will use the global routing table
to send the packets.
Note Cisco recommends binding services to next hops.
For L2TP dial-in or dial-out tunnel services, virtual-access interfaces are created dynamically on the
service side for each user. SSG automatically determines the binding when the virtual-access interface
is created.
SSG allows next-hop bindings to be configured in a next-hop table on the AAA server. The next-hop
table is downloaded by SSG upon startup. The next-hop table uses the Next-Hop Gateway attribute to
specify the next-hop key for a service. Each SSG uses its own next-hop gateway table, which associates
the next-hop key with an actual IP address.
Open Garden (Unauthenticated) Services

The following sections provide information about SSG open garden services:
• Overview of SSG Open Garden Services, page 165
• Access Control Lists in Open Garden Services, page 166
• Hierarchical Policing in Open Garden Services, page 166
Overview of SSG Open Garden Services

An open garden is a collection of Web sites or networks that unauthenticated subscribers can access.
Subscribers do not have to provide authentication information before accessing an open garden service.
In contrast, walled garden refers to a collection of Web sites or networks that subscribers can access after
providing minimal authentication information. Figure 11 shows a network topology that includes open
gardens.
Figure 11 Open Garden Network Topology
Open garden 1
SSG
Open garden 2
62669
Next-hop gateway
Open Garden Service Binding

Whereas SSG-authenticated services must be bound to an interface or next hop, it is not necessary to
bind open garden services that are reachable via the global-ip routing table. Service binding becomes
mandatory for open garden services that are routed via a next hop.

78-17497-01 165
Access Control Lists in Open Garden Services

SSG supports upstream and downstream access control lists (ACLs) in open garden service profiles.
Packets that match the open garden service are matched against the access control lists before being
forwarded. If a packet is allowed by the access control list, the packet is routed to the open garden
service. If the packet is denied by the access control list, the packet is processed by the rest of the
configured SSG features (such as TCP redirect or transparent autologon) before being dropped. The
ACLs are configured as the Cisco vendor-specific attributes (VSAs).
Hierarchical Policing in Open Garden Services

SSG supports hierarchical policing attributes in open garden service profiles. When an open garden
service policy is configured for hierarchical policing, SSG polices all traffic going to and from the open
garden service.
Note Hierarchical policing for open garden services works slightly differently from the way it works for
authenticated connected services. For subscribed or authenticated services, each connection inherits
policing parameters from the service. For open garden services, policing parameters apply to the service
(all traffic to and from the service) since no connections are present.
SSG Uplink Interface Redundancy and Load Balancing

This section contains the following concepts:
• Overview of SSG Interface Redundancy, page 166
Overview of SSG Interface Redundancy

In SSG, each service is associated with an uplink interface: either the service is bound to a next hop,
which is routable through an interface, or the service is bound directly to the interface.
Before Cisco IOS Release 12.3(8)T, SSG had the limitation of only being able to bind a service to one
uplink interface, even if the next hop through which the service was bound was reachable via multiple
interfaces. In Cisco IOS Release 12.3(8)T, SSG interface redundancy was introduced. SSG interface
redundancy allows services to be associated with more than one next hop or interface to protect against
link failures. When a service is bound to multiple interfaces, these interfaces can be grouped into an
interface group.
If a service is configured for multiple uplink interfaces, downstream traffic is allowed on all of the
interfaces for any service bound to even one of those interfaces.
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. This is because NAT will be applied for
the user on all the uplink interfaces in the uplink-interface group.
This feature is supported on all interfaces that support SSG, including subinterfaces and VLAN
interfaces.

166 78-17497-01
Failover
When redundant bindings are configured for a service, the order in which SSG selects these bindings to
be used to reach a service depends on the distance metric that is assigned to the service binding. The
interface for the service binding with the lowest weight 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 service connection
to the interface associated with the next-lowest weight. When the primary uplink interface or next hop
becomes available again, SSG switches back to using the primary interface.
SSG interface redundancy can be configured for services, including open garden and walled garden
services, and the default network.
Load Balancing
If the same distance metric is assigned to multiple service bindings, SSG will perform load-balancing
across those bindings. If one of the bindings fails, SSG will move the traffic to the rest of the working
bindings. If the binding that failed comes back up again, the traffic is automatically shared among all the
active bindings.
Load-balancing with the same distance metric to multiple bindings and failover with different distance
metrics can be configured together for the same service.
Configuration Information
SSG uplink interface redundancy is configured by binding a service to more than one next hop or
interface and grouping the redundant interfaces to ensure that SSG treats them similarly. To bind services
to interfaces or next hops, see the “Configuring SSG Support for Services” section on page 171. To
group redundant uplink interfaces, see the “Establishing Initial SSG Communication” module.
SSG Uplink Interface Redundancy Topologies

The SSG Interface Redundancy feature supports uplink interface redundancy in the following network
topologies:
• Multiple Next Hops per Service, page 167
• Multiple Uplink Interfaces with a Single Next Hop, page 168
• Multiple Uplink Interfaces with No Next Hop, page 168
• Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops, page 168
Multiple Next Hops per Service
Figure 12 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.

78-17497-01 167
Figure 12 Multiple Next Hops per Service: Sample Topology
Next hop 1
Uplink 1
SSG Service
103656
Uplink 2
Next hop 2
Multiple Uplink Interfaces with a Single Next Hop
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 in the IP routing table.
Figure 13 Multiple Uplink Interfaces with a Single Next Hop: Sample Topology
Uplink 1
SSG Next hop Service
103657
Uplink 2
Multiple Uplink Interfaces with No Next Hop
interfaces that are directly connected to the service. These uplink interfaces could also be tunnel
interfaces.
Figure 14 Multiple Uplink Interfaces with No Next Hop: Sample Topology
Uplink 1
SSG Service
103658
Uplink 2
Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops
Figure 15 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.

168 78-17497-01
Figure 15 Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops:
Sample Topology
Uplink 1
103659
SSG Service
Uplink 2
DNS Packet Handling

When SSG receives DNS requests, the DNS packets are first processed for the user connection. If the
domain match is not found, the packets are processed for open gardens.
In the upstream direction, SSG handles DNS packets by first looking up the domain in the
connected-service list. If a match is not found in the connected-service list, the open garden service list
is checked. If the domain is not found in the open garden service list and the user has a connected Internet
service (0.0.0.0/0), the DNS request is forwarded to that domain. If the user is not connected to an
Internet service and there is an open garden Internet service, the DNS request is forwarded to the open
garden Internet domain.
In the downstream direction, SSG handles DNS response packets in the same order in which they are
handled in the upstream direction.
Note DNS packet processing in an open garden configuration was handled differently by SSG in Cisco IOS
Release 12.2(2)B and earlier releases. In those releases, DNS domain lookup was performed first in
the domains configured in the open garden services. If a match was not found, DNS domain lookup
was performed in the connected services of the user.
If SSG receives a packet that is not destined for the open garden, SSG checks the source IP address of
the packet to see if the subscriber is authenticated. If SSG recognizes the IP address, the subscriber is
authenticated and SSG forwards the packet. If the subscriber is not authenticated and the packet is not a
DNS packet, SSG drops the packet.
SSG Transparent Pass-Through

When enabled, transparent pass-through allows unauthenticated subscriber traffic to be routed through
SSG in either direction. These are some of the benefits of SSG transparent pass-through:
• Makes SSG easier to integrate into an existing network by not requiring users who have
authenticated with network access servers (NAS) to authenticate with SSG
• Allows management traffic (such as TACACS+, RADIUS, and SNMP) from NASs connected to the
host network to pass through to the service provider network
• Allows visitors or guests to access certain parts of the network

78-17497-01 169
How to Configure Services for Subscribers
Filters can be configured to control transparent pass-through traffic. These filters can be configured
locally on the router or on the AAA server in a transparent pass-through filter pseudo-service profile.
For information about transparent pass-through filter pseudo-service profiles, see the RADIUS Profiles
and Attributes for SSG module.
Service Profile Caching

The Service Profile Cache feature enables SSG to use a cached copy of a service profile instead of
downloading the profile from a RADIUS server every time a user logs on to the service.
SSG caches the service profile whenever the first user logs on to the service and uses this cached profile
when another user attempts to log on to the same service.
The following sequence describes how service profiles are cached:
• A user selects a service on the service logon page that SESM displays.
• SSG receives the service logon request and looks up the service profile using the service name.
• If the service profile exists and it is active, SSG uses the service profile to process the logon request.
• If the service profile exists, but it is inactive (for example, SSG is currently downloading the profile),
SSG queues the logon request and processes the request after the service profile is downloaded.
SSG runs a timer for refreshing the service profiles from the RADIUS server. When the profile changes
on the RADIUS server, the SSG timer process periodically updates the cached profile to ensure that the
service information is current.
If the service profile fails to update, SSG retains the cached service profile. When a new user connects
to the SSG, SSG downloads the service profile again. If SSG cannot download the service profile, the
user is not allowed to log on to the service.
Service profile caching is enabled by default.

• Configuring a Local Service Profile Using the Cisco IOS CLI, page 170
• Configuring SSG Support for Services, page 171
• Configuring SSG to Support L2TP Dial-In Tunnel Services, page 173
• Configuring SSG to Support L2TP Dial-Out Services, page 177
• Configuring SSG Open Garden Services, page 186
• Configuring SSG Transparent Pass-Through, page 187
• Monitoring and Maintaining SSG Support for Services, page 188
• Troubleshooting SSG Support for Services, page 190
Configuring a Local Service Profile Using the Cisco IOS CLI

Service profiles are most commonly configured on the remote AAA server and downloaded by the router
as needed. For information about RADIUS profiles and VSAs for SSG, see the “RADIUS Profiles and
Attributes for SSG” module.

170 78-17497-01
You can also configure service profiles directly on the router by using the Cisco IOS command line
interface. Perform this task to configure a local service profile.
Note 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.
SUMMARY STEPS
1. local-profile service-name
2. attribute radius-attribute-id [vendor-id] [cisco-vsa-type] attribute-value
3. Repeat Step 2 for each attribute that you want to add to the service profile.
DETAILED STEPS
Configuring SSG Support for Services

Step 1 local-profile service-name Configures a local RADIUS service profile and enters
profile configuration mode.
Example:
Router(config)# local-profile service1
Step 2 attribute radius-attribute-id [vendor-id] Configures an attribute in a local RADIUS service profile.
[cisco-vsa-type] attribute-value
• See the “RADIUS Profiles and Attributes for SSG”
module for information about RADIUS profiles and
Example: VSAs for SSG.
Router(config-prof)# attribute 26 9 251
"Owww.opengarden.com" • Only attributes that can appear in RADIUS
Access-Accept packets can be configured using the
attribute command.
Step 3 Repeat Step 2 for each attribute that you want to add to the service profile.
Perform this task to configure SSG support for authenticated services (pass-through, proxy, and L2TP
services).
SUMMARY STEPS
1. ssg bind service service-name {ip-address | interface-type interface-number} [distance-metric]

2. ssg service-search-order {local | remote | local remote | remote local}
3. ssg next-hop download [profile-name] [profile-password]
4. ssg service-cache [refresh-interval minutes]
5. exit

78-17497-01 171
DETAILED STEPS

Step 1 ssg bind service service-name {ip-address | Specifies the interface for a service.
interface-type interface-number}
[distance-metric] • Every service must be bound to an uplink interface,
either by defining the binding in the next-hop table or
by using the ssg bind service command. If the service
Example: binding is defined in the next-hop table, then it is not
Router(config)# ssg bind service sample-service
necessary to bind the service by using the ssg bind
atm 1/0.1
service command.
• To bind a service to more than one interface for
interface redundancy, you can enter this command more
than once.
• To control the routing of upstream traffic, use the
distance-metric argument. SSG uses the interface that
has the lowest metric. The default value for the
distance-metric is 0.
Step 2 ssg service-search-order {local | remote | (Optional) Specifies the order in which SSG searches for a
local remote | remote local} service profile.
• The local keyword specifies that service profiles are
Example: configured using local profile.
Router(config)# ssg service-search-order local
• The default value for the service search order is
remote; that is, the SSG searches for service profiles on
the RADIUS server.
Step 3 ssg next-hop download [profile-name] (Optional) Downloads the next-hop table from a RADIUS
[profile-password] server.
Example:
Router(config)# ssg next-hop download
next-hop-tbl next-hop-tbl-passwd
Step 4 ssg service-cache [refresh-interval minutes] (Optional) Allows SSG to cache the user profiles of
non-PPP users.
Example:
Router(config)# ssg profile-cache
Example:
Router(config)# exit
What to Do Next
If you are configuring L2TP services, you must also perform the tasks in the “Configuring SSG to
Support L2TP Dial-In Tunnel Services” section on page 173.

172 78-17497-01
Configuring SSG to Support L2TP Dial-In Tunnel Services

SSG can be configured to support L2TP dial-in services with configured with L2TP dial-in IOS
configurations.
To configure SSG to support L2TP, perform the tasks in the following sections:
• Configuring SSG to Serve as a LAC
• Configuring a VPDN Group
• Configuring RADIUS Profiles for SSG Support of L2TP
• Configuring the LNS
To verify SSG support for L2TP dial-in tunnel services, perform the task in the following section:
• Monitoring and Maintaining SSG Support for L2TP Services
Configuring SSG to Serve as a LAC

Perform this task to configure SSG to serve as an LAC.
SUMMARY STEPS
1. vpdn enable
2. interface slot/port
DETAILED STEPS

Step 1 vpdn enable Enables L2TP functionality.
Example:
Router(config)# vpdn enable
Step 1 interface type slot/port Enables NAT on the downlink interface.
Example:
Router(config)# interface 1/0
Configuring a VPDN Group

Perform this task to configure SSG to support virtual private dialup network (VPDN) group names in the
SSG tunnel service profile.
SUMMARY STEPS
1. vpdn-group name

78-17497-01 173
DETAILED STEPS

Step 1 vpdn-group name Associates an SSG service profile to the
specified VPDN group name.
Example:
Router(config)# vpdn-group mytunnel
Configuring RADIUS Profiles for SSG Support of L2TP

To configure support of L2TP, you must add the following vendor-specific attributes to the service
profiles:
• Cisco AVpair VPDN Attributes
• Service-Info VPDN Attributes
Cisco AVpair VPDN Attributes

Cisco AVpair VPDN attributes can be configured in either of two ways:
• By configuring the vdpn-group-name in the service profile and the VDPN group on the router.
• By configuring VPDN attributes within the service profile.
Table 7 lists the Cisco AVpair attributes used in the service profile to configure VPDN.
Table 7 Cisco AV Pair Attributes
Attribute Description
VPDN IP Address Specifies the IP addresses of the home gateways (L2TP network
servers) to receive the L2TP connections.
VPDN Tunnel ID Specifies the name of the tunnel that must match the tunnel ID
specified in the LNS VPDN group.
L2TP Tunnel Password Specifies the secret (password) used for L2TP tunnel
authentication.
vpdn-group-name Specifies the vpdn-group-name that will be configured on the
router.
Service-Info VPDN Attributes

Table 8 lists the Service-Info attributes used in the service profile to define the L2TP service parameters.
Table 8 Service-Info Attributes
Type of Service Specifies proxy, tunnel, or pass-through service. L2TP always uses
tunnel service.
MTU Size Specifies the PPP maximum transmission unit (MTU) size for SSG
as an LAC. By default, the PPP MTU size is 1500 bytes.
Service Route Specifies the networks available to the user for this service.

174 78-17497-01
Configuring the LNS

To configure the L2TP network server (LNS) to accept L2TP dial-in tunnels from SSG, perform the steps
in this section.
SUMMARY STEPS
1. username name password secret

2. vpdn-group number
3. accept-dialin
4. protocol l2tp
5. virtual-template template-number
6. exit
7. terminate-from hostname hostname
8. l2tp tunnel password password
9. exit
10. interface virtual-template number
11. ip unnumbered interface-type interface-number
12. peer default ip address pool pool-name
13. ppp authentication {chap | chap pap | pap chap | pap}
14. ip local pool pool-name start-address end-address
DETAILED STEPS

Step 1 username name password secret (Optional) Specifies the password to be used
for PAP and CHAP.
Example: • Subscribers can also be defined and
Router(config)# username myusername password mypassword authenticated on the AAA server serving
the LNS.
Step 2 vpdn-group number Selects the VPDN group.
• Each L2TP tunnel requires a unique
Example: VPDN group.
Router(config)# vpdn-group 3
• Enters VPDN group configuration mode.
Step 3 accept-dialin Creates an accept dial-in VPDN group and
enters VPDN Accept-dialin group
configuration mode.
Example:
Router(config-vpdn)# accept-dialin
Step 4 protocol l2tp Configures the VPDN to use L2TP.
Example:
Router(config-vpdn-acc-in)# protocol l2tp

78-17497-01 175

Step 5 virtual-template template-number Specifies which virtual template will be used
to clone virtual access interfaces.
Example:
Router(config-vpdn-acc-in)# virtual-template 1234
Step 6 exit Returns to VPDN group configuration mode.
Example:
Router(config-vpdn-acc-in)# exit
Step 7 terminate-from hostname hostname Specifies the tunnel ID that will be required
when a VPDN tunnel is accepted.
Example: • This must match the VPDN tunnel ID
Router(config-vpdn)# terminate-from hostname myhostname configured in the RADIUS service
profile.
Step 8 l2tp tunnel password password Identifies the password that the router will use
for tunnel authentication.
Example:
Router(config-vpdn)# l2tp tunnel password mypassword
Step 9 exit Returns to global configuration mode.
Example:
Router(config-vpdn)# exit
Step 10 interface virtual-template number Creates a virtual template interface that can
clone new virtual access interfaces.
Example:
Router(config)# interface Virtual-Template 1234
Step 11 ip unnumbered interface-type interface-number Configures the interface as unnumbered and
provides a local address.
Example: • Enters interface configuration mode.
Router(config-if)# ip unnumbered FastEthernet 1/0
Step 12 peer default ip address pool pool-name Specifies the pool from which to retrieve the
IP address to assign to a remote peer dialing in
to the interface.
Example:
Router(config-if)# peer default ip address pool mypool
Step 13 ppp authentication {chap | chap pap | pap chap | pap} Specifies the order in which the CHAP or PAP
protocols are requested on the interface.
Example:
Router(config-if)# ppp authentication {chap | chap pap |
pap chap | pap}
Step 14 ip local pool pool-name start-address end-address Creates a local IP address pool named
mypool, which contains all local IP addresses
from 172.16.23.0 to 172.16.23.255.
Example:
Router(config-if)# ip local pool mypool 172.16.23.0
172.16.23.255

176 78-17497-01
Monitoring and Maintaining SSG Support for L2TP Services

Perform this task to monitor and maintain SSG support of L2TP tunnel services.
SUMMARY STEPS
1. enable
2. show vpdn tunnel [all | packets | state | summary | transport] [id | local-name | remote-name]
3. show vpdn session [all [interface | tunnel | username]| packets | sequence | state | timers |
window]
4. clear vpdn tunnel l2tp remote-name local-name
DETAILED STEPS
t

Step 1 enable Enables higher privilege levels, such as privileged EXEC
mode.
Example: • Enter your password if prompted.
Router> enable
Step 2 show vpdn tunnel [all | packets | state | Displays VPDN tunnel information, including tunnel
summary | transport] [id | local-name | protocol, ID, packets sent and received, retransmission
remote-name]
times, and transport status.
Example:
Router# show vpdn tunnel summary
Step 3 show vpdn session [all [interface | tunnel | Displays VPDN session information, including interface,
username]| packets | sequence | state | timers tunnel, username, packets, status, and window statistics.
| window]
Example:
Router# show vpdn session
Step 4 clear vpdn tunnel l2tp remote-name local-name Shuts down a specific tunnel and all the sessions within the
tunnel.
Example:
Router# clear vpdn tunnel l2tp local2 local3
Configuring SSG to Support L2TP Dial-Out Services

SSG dial-out service provides mobile users with a way to connect securely to their SOHOs through the
PSTN.
• Prerequisites for SSG L2TP Dial-Out, page 178
• Restrictions for SSG L2TP Dial-Out, page 178
Before you configure SSG support for L2TP dial-out service, you should understand the following
concepts:
• Overview of SSG L2TP Dial-Out, page 178

78-17497-01 177
• SSG L2TP Dial-Out Service Logon Through SESM, page 179

• SSG L2TP Dial-Out Service Account Logon with Structured Username and Without SSG
Auto-Domain, page 180
• SSG L2TP Dial-Out Service Logon with Structured Username and with SSG Auto-Domain,
page 180
Perform the following tasks to configure SSG support for L2TP dial-out services:
• Configuring a Global Dial-Out Service Profile, page 181
• Configuring the User Service Profile for L2TP Dial-Out Services, page 182
• Configuring a DNIS Filter, page 182
• Monitoring SSG L2TP Dial-Out, page 183
• Troubleshooting SSG L2TP Dial-Out User Logon Failures, page 184
• Troubleshooting SSG L2TP Dial-Out Service Login Failures, page 185
Prerequisites for SSG L2TP Dial-Out

Before configuring SSG for L2TP dial-out service, you must first perform the tasks in the “Configuring
SSG to Support L2TP Dial-In Tunnel Services” section on page 173.
Restrictions for SSG L2TP Dial-Out

SSG L2TP Dial-Out does not support the following functionality:
• Layer 2 Tunneling Protocol (L2TP) dial-out as a primary service for PPP users
• Challenge Handshake Authentication Protocol (CHAP) authentication for dial-out tunnel services
• Dial-out tunnel support for protocols other than L2TP protocols, such as Layer 2 Forwarding
Protocol (L2F).
Overview of SSG L2TP Dial-Out

The SSG L2TP Dial-Out feature provides mobile users with a way to securely connect to their SOHOs
through the PSTN.
To provide SSG L2TP dial-out functionality, SSG requires a digital number identification service
(DNIS) number for the SOHO to which the user wants to connect, the address of the L2TP Access
Concentrator (LAC) closest to the SOHO, and configured tunnel parameters to establish a tunnel to the
LAC.
Users can access SSG L2TP dial-out service by selecting it using Cisco SESM from the list of subscribed
services, or by using a structured username during user login (such as for RADIUS-proxy users). The
user must provide the DNIS number when using either method of connecting to the dial-out service.

178 78-17497-01
Figure 16 SSG L2TP Dial-Out Network
Subscribers Services
144.10.50.10 10.10.10.1
SESM AAA
IP Access PSTN
L2TP
SSG LAC
75494
144.10.50.11 10.10.10.1
SSG L2TP Dial-Out Service Logon Through SESM

A user can access SSG L2TP dial-out functionality by selecting the dial-out tunnel service on the SESM.
After a user selects the dial-out service, the SESM displays a page for the entry of the user’s name and
password. SSG then downloads the service profile for the dial-out service.
When a user attempts to log on to a dial-out service, the username entered into the SESM must have a
numerical realm that is a DNIS prefix; for example, abc@091805318090. If the DNIS prefix that the user
enters is found on the DNIS exclusion list, the logon is rejected. If the entered DNIS prefix is valid, a
tunnel session to the LAC is established, and SSG starts PPP negotiations with the SOHO. The user is
then authenticated at the SOHO.
If you configure the X attribute in the service profile, the full username (abc@091805318090) is sent for
authentication. Otherwise, only the username (abc) is authenticated.
Upon successful authentication, the SOHO assigns an IP address to the user, and Network Address
Translation (NAT) for the assigned IP address is performed in SSG.

78-17497-01 179
Figure 17 SSG L2TP Dial-Out Service Logon Through SESM
Service logon page from SESM
user abc@091805318090
password *******
SGSN
PPP
LAC 091805318090
Dial-up Soho
network
L2TP
GN backbone IP backbone
GGSN SSG
[LNS] L2TP Dial-up Soho
network
LAC 03962951
PPP
SGSN
user def@03962951
password *******
75493
SSG L2TP Dial-Out Service Account Logon with Structured Username and Without SSG
Auto-Domain
When a user attempts an account logon with a structured username and the SSG Auto-domain feature is
not enabled, the entered username is sent to a local authentication, authorization, and accounting (AAA)
server for user authentication. If the username entered is a structured username, SSG does not interpret
the full username as user and domain. If the username is entered as “user@DNIS”, the full username is
used for user authentication.
If a user has a dial-out tunnel service configured as an autologon service and does not specify a username
and password along with the service name in the user profile, the username and password entered for
account logon are used. If the username and password are given with the service name in the user profile,
then that username and password are used. The username entered in either case must be “user@DNIS”.
The DNIS portion of the username is used as the dial string to dial from the LAC to the SOHO.
SSG L2TP Dial-Out Service Logon with Structured Username and with SSG Auto-Domain
When the SSG Auto-domain feature is enabled, a full username must be entered by the user at the
account logon page if the user wants to perform service selection by using the DNIS number. SSG
interprets the full username as username and domain. For “user@DNIS”, “user” is the username and
“DNIS” is the domain. This “DNIS” domain must be a numerical value; for example, “user@3962962.”
You can select the dial-out global service that is available to a user who performs an account logon with
a structured username (user@DNIS) by configuring the dnis-prefix all service command.

180 78-17497-01
SSG Auto-domain can be configured to work in basic or extended mode. In basic mode, the SSG
Auto-domain profile downloaded from the AAA server is a service profile. In extended SSG
Auto-domain mode, the SSG Auto-domain profile downloaded from the AAA server is a “virtual-user”
profile. In the virtual-user profile, the dial-out service is configured as the primary autologon service.
When SSG Auto-domain is configured, SSG parses the structured username. If the domain part of the
username is a DNIS prefix, the SSG Auto-domain profile is downloaded. If the SSG Auto-domain profile
has not been configured or the DNIS prefix is included in the DNIS exclusion list, the account logon is
rejected.
If the account logon is successful and the configured service is a dial-out service, SSG establishes a
tunnel session with the LAC. The IP address of the LAC must be configured in the global service profile.
SSG uses the DNIS number that was entered as part of the username as the dial string to dial out to the
SOHO from the LAC. When the PPP session begins successfully, the user is authenticated at the SOHO.
If the X attribute is configured in the SSG Auto-domain profile, the full username is sent for
authentication.
SSG performs Network Address Translation (NAT) for the user’s IP address for a tunnel by default. If
you enter the no nat user-address command when SSG Auto-domain is configured, SSG does not
perform NAT on the user’s IP address. Rather, the IP address assigned by the SOHO is assigned to the
user. This configuration is valid only for RADIUS-proxy users where the AAA server (in this case, SSG)
is assigning the IP address to the user.
Configuring a Global Dial-Out Service Profile

Perform this task to configure a global dial-out service profile.
SUMMARY STEPS
1. ssg dial-out
2. dnis-prefix all service service-name
DETAILED STEPS

Step 1 ssg dial-out Enters SSG dial-out configuration mode.
Example:
Note There is no command to enable or disable the SSG
Router(config)# ssg dial-out
L2TP Dial-Out feature. An L2TP dial-out tunnel is
established if the service profile contains the
“vpdn:dout-type=2” attribute.
Step 2 dnis-prefix all service service-name Configures the dial-out global service name.
• The global service is configured for users who are
Example: doing an account logon with a structured username.
Router(config-dial-out)# dnis-prefix all
service service1
• service-name—Name of the dial-out global service.

78-17497-01 181
Configuring the User Service Profile for L2TP Dial-Out Services

When you configure the service profile for a dial-out tunnel service, configure the same parameters that
are used for dial-in tunnel service, along with the additional Cisco attribute value (AV) pair
“vpdn:dout-type=2” in the user profile. The 2 represents the L2TP protocol. Only the L2TP protocol is
supported for dial-out tunnels.
To configure SSG to send the mobile station integrated services digital network (MSISDN) number
along with the DNIS number to the LAC and the SOHO, the service profile must contain the Y attribute.
By default, only the DNIS number is sent when the dial-out tunnel is being established. When the
MSISDN/DNSI VSA (Y-attribute) is present in the service, the dial string that is passed to the LAC takes
the following format:
DNIS-number_delimiter MSISDN-number
The delimiter is a configurable character. It can be any regular expression character (A, B, C, D, 0–9, #,
*, \ , $, . , ^) that is not in the DNIS or in the MSISDN number. If you do not specify a delimiter, the “@”
character is the default delimiter.
If there is no MSISDN for the subscriber, only the DNIS number is sent as the dial string.
Table 9 MSISDN/DNIS VSA
Subattribute ID
Attribute ID Vendor ID and Type Attribute Name Subattribute Data
26 9 251 MSISDN/DNIS Y—Service-information code for
sending MSISDN with DNIS
G—Delimiter character that separates
the DNIS number from the MSISDN
number.
Configuring a DNIS Filter
DNIS Filters
To block PSTN calls to unwanted DNIS numbers, such as free phone or international numbers, you can
configure a DNIS filter. DNIS filters can be locally configured through the command line interface (CLI)
or received from a AAA profile.
Perform this task to configure a DNIS filter locally on the router.
SUMMARY STEPS
1. ssg dial-out
2. exclude dnis-prefix dnis-prefix
3. Repeat Step 2 to add DNIS prefixes to the DNIS exclusion list.
4. download exclude-profile profile-name password

182 78-17497-01
DETAILED STEPS

Step 1 ssg dial-out Enters SSG dial-out configuration mode.
Example:
Router(config)# ssg dial-out
Step 2 exclude dnis-prefix dnis-prefix (Optional) Configures the DNIS filter by adding a DNIS prefix to
the DNIS exclusion list.
Example: • dnis-prefix—The DNIS prefix to add to the DNIS exclusion
Router(config-dial-out)# exclude list.
dnis-prefix 18085288110
Step 3 (Optional) Repeat Step 2 to add DNIS prefixes to the DNIS exclusion list.
Step 4 download exclude-profile profile-name (Optional) Downloads the DNIS exclusion list locally or from
password AAA.
• profile-name—Name of the DNIS exclusion list.
Example:
Router(config-dial-out)# download
• password—Password of the DNIS exclusion list.
exclude-profile dnis_exclude_profile
safe123
Monitoring SSG L2TP Dial-Out

Perform this task to monitor the SSG L2TP Dial-Out feature.
SUMMARY STEPS
1. show ssg dial-out exclude-list

2. show ssg service [service-name]
DETAILED STEPS

Step 1 show ssg dial-out exclude-list Displays information about the DNIS exclusion list.
Example:
Router# show ssg dial-out exclude-list

78-17497-01 183

Step 2 show ssg service [service-name] Displays detailed information about a service.
• If no service name is entered, this command displays a
Example: list of all services.
Router# show ssg service service1
• service-name—(Optional) Name of an active SSG
service.
Step 3 show ssg connection ip-address service-name Displays the connections of a given host and a service name.
[interface]
• ip-address—IP address of an active SSG connection.
This is always a subscribed host.
Example:
Router# show ssg connection 10.1.1.19 InstMsg
• service-name—Name of an active SSG connection.
• interface—(Optional) The IP address through which
the host is connected.
Troubleshooting SSG L2TP Dial-Out User Logon Failures

Perform this task to troubleshoot L2TP dial-out user logon failures.
SUMMARY STEPS

2. debug ssg radius
3. debug ssg ctrl-err
DETAILED STEPS
Step 1 debug ssg ctrl-events

Enter the debug ssg ctrl-events command to display event messages for the control modules, including
all modules that manage user authentication and service logon and logoff.
SSG-CTL-EVN: AAA Response is bad

.
.
.
SSG-CTL-EVN: Failed to get user info. user=dt-user90, pwd=*****
If either of the two outputs above is displayed, the user profile does not exist, the password is incorrect
in AAA, or the AAA is not configured. Enable AAA by entering the aaa new-model command.
Step 2 debug ssg radius
Enter the debug ssg radius command to display messages about the communication between the AAA
server and the router.
Router# debug ssg radius
RADIUS: No radius servers defined!
The output above is displayed if the RADIUS server is not configured or is not reachable. Configure the
RADIUS server by entering the radius-server host command.

184 78-17497-01
If the debug ssg radius command displays the following output, there is a RADIUS server key
mismatch:
RADIUS: Response (159) failed decrypt
Configure the correct key by entering the radius-server key ssg command.
Step 3 debug ssg ctrl-err
Enter the debug ssg ctrl-err command to display error messages for the control modules, including all
modules that manage user authentication and service logon and logoff.
Router# debug ssg ctrl-err
SSG-CTL-ERR: Unable to find SSG sub-block from ATM3/0.1
The output above indicates that the ATM3/0.1 interface, where the user is coming from, is not configured
as a downlink interface. SSG requires that all the interfaces to the subscribers be bound as downlink
interfaces. Enter the ssg direction downlink command in interface configuration mode to configure the
interface as downlink.
Troubleshooting SSG L2TP Dial-Out Service Login Failures

Perform this task to troubleshoot L2TP dial-out service login failures.
Step 1 debug ssg ctrl-events

Enter the debug ssg ctrl-events command.
SSG-CTL-EVN: Invalid DNIS number for dialout tunnel service
The output above indicates that an invalid DNIS number has been configured. The DNIS number
should be configured according to the E.165 standard. Valid DNIS numbers can contain the
following characters: A, B, C, D, 0–9, #, *, and “.”, and they can start with + and end with T.
Any issues on the LAC or SOHO side will cause the following outputs in the debug ssg ctrl-events
command:
SSG-VPDN-CTL-EVN: VPDN module failed to establish tunnel
or
SSG-VPDN-CTL-EVN: Failed to establish call..informing SSG
Follow the steps below to troubleshoot this problem:

a. After giving the service logon request, enter the show vpdn tunnel command to view the tunnel
status (the tunnel will time out after some time).
b. If the tunnel has come up, skip this step. If the tunnel is not up, enable the debug vpdn l2x-events
and debug vpdn l2x-errors commands on the SSG and on the LAC.
Common problems are tunnel ID mismatch and destination IP not reachable.
c. Once the tunnel is up, problems can appear on the dialer interface.
• Enable debug ppp negotiation and debug ppp authentication commands.
• If no PPP debug messages are seen, it is confirmed that the problem is with the dialer interface.

78-17497-01 185
d. Enable the debug dialer and debug isdn q921, 931 commands on the LAC and on the SOHO. A
common problem is ISDN status “not established.”
For Dialer interface configuration problems, cut and paste the configuration given in the
“Configuration Examples” section on page 14 again and look for any command rejections. Most
problems will have to do with ISDN (Layer 2).
Common problems found in the PPP debug messages are authentication failed and IPCP negotiation
failed.
Configuring SSG Open Garden Services

Perform this task to configure a service as an open garden service.
SUMMARY STEPS
1. local-profile [profile-name]
2. attribute 26 9 251 “Rip-address;subnet-mask”
3. attribute 26 9 251 “Dip-address”
4. attribute 26 9 251 “Odomain-name”
5. exit
6. ssg open-garden profile-name
7. ssg bind service service {ip-address | interface-type interface-number}
DETAILED STEPS

Step 1 local-profile profile-name Creates a local service profile and enters
profile configuration mode.
Example:
Router(config)# local-profile myprofile
Note It is not necessary to create a
local service profile if the service
profile is created on the RADIUS
server.
Step 2 attribute 26 9 251 “Rip-address;subnet-mask” (Service Route attribute) Specifies the
network available to the service.
Example: • You can add multiple networks to an
Router(config-prof)# attribute 26 9 251 open garden service.
“R10.10.1.1;255.255.0.0”
• Repeat step as necessary.

186 78-17497-01

Step 3 attribute 26 9 251 “Dip-address” (DNS Server Address attribute) Specifies
the DNS server for the service.
Example: • Enter this command twice to specify
Router(config-prof)# attribute 26 9 251 two DNS servers for DNS fault
“D10.10.2.2” tolerance. SSG will send DNS
requests to the first DNS server in its
list. If the first server does not
respond to the requests, SSG will
send the requests to the second DNS
server.
Step 4 attribute 26 9 251 “Odomain-name” (Domain Name attribute) Specifies the
domain name that gets DNS resolution
from the DNS server specified in Step 3.
Example:
Router(config-prof)# attribute 26 9 251 “SSG1” • Repeat step as necessary. You can
add multiple domain names to an
open garden service.
Step 5 exit Returns to global configuration mode.
Example:
Router(config-prof)# exit
Step 6 ssg open-garden profile-name Designates the service as an open garden
service.
Example:
Router(config)# ssg open-garden profile-name
Step 7 ssg bind service service {ip-address | Specifies the bindings for the service.
interface-type interface-number}
Note This step is required only if the
open garden is routed through a
Example: next-hop gateway.
Router(config)# ssg bind service og2 10.5.5.1
Configuring SSG Transparent Pass-Through

Transparent pass-through allows unauthenticated traffic to pass through SSG in either direction without
SSG processing. Filters can be configured to control transparent pass-through traffic. These filters can
be configured locally on the router or on the AAA server in a transparent pass-through filter
pseudo-service profile. For information about configuring transparent pass-through filter pseudo-service
profiles on the AAA server, see the “Configuring SSG to Serve as a RADIUS Proxy” module.
Perform this task to configure transparent pass-through.
SUMMARY STEPS
1. ssg pass-through [filter {ip-access-list | ip-extended-access-list | access-list-name | download

[profile-name | profile-name profile-password]} [downlink | uplink]}]
2. end
3. show ssg pass-through-filter [begin expression | exclude expression | include expression]

78-17497-01 187
DETAILED STEPS

Step 1 ssg pass-through [filter {ip-access-list | Enables transparent pass-through, which allows
ip-extended-access-list | access-list-name | unauthenticated traffic to bypass SSG processing in either
download [profile-name | profile-name
profile-password]} [downlink | uplink]}]
direction without modification.
• Use the filter options to specify access control for
packets.
Example:
Router(config)# ssg pass-through filter • Use the download options to download a service profile
download filter01 cisco and use its filters as default filters.
Step 2 end Returns to privileged EXEC mode.
Example:
Router(config)# end
Step 3 show ssg pass-through-filter [begin expression | (Optional) Displays the downloaded filter for transparent
exclude expression | include expression] pass-through.
• Use this command to verify transparent pass-through
Example: configuration.
Router# show ssg pass-through-filter
Verifying SSG Transparent Pass-Through: Example

The following example shows how to verify SSG transparent pass-through by using the show ssg
pass-through-filter command.
Service name: filter01

Password: cisco
Direction: Uplink
Extended IP access list (SSG ACL)

permit tcp 172.16.6.0 0.0.0.255 any eq telnet
permit tcp 172.16.6.0 0.0.0.255 192.168.250.0 0.0.0.255 eq ftp
Monitoring and Maintaining SSG Support for Services

Perform this task to monitor and maintain SSG support for services.
SUMMARY STEPS
1. show ssg service [service-name [begin expression | exclude expression | include expression]]
2. show vpdn tunnel l2tp
3. show ssg open-garden
4. show ssg interface [brief]
5. show ip nat translations
6. clear ssg open-garden

188 78-17497-01
7. clear ssg service profile-name

8. show ssg pass-through-filter [begin expression | exclude expression | include expression]
9. clear ssg pass-through-filter
DETAILED STEPS

Step 1 show ssg service [service-name [begin Displays information for an SSG service.
expression | exclude expression | include
expression]] • If no service name is entered, the command displays
information for all services.
Example:
Router# show ssg service
Step 2 show vpdn tunnel l2tp Shows L2TP tunnels established for tunnel services.
Example:
Router# show vpdn tunnel l2tp
Step 3 show ssg open-garden Shows the list of open-garden services created by the ssg
open garden command.
Example:
Router# show ssg open-garden
Step 4 show ssg interface [brief] Lists the SSG-enabled interfaces as uplink, downlink, and
featurelink.
Example: • Lists hosts on downlink interfaces and services bound
Router# Show ssg interface brief to the uplink interfaces.
Step 5 show ip nat translations Lists the NAT entries on SSG.
Example:
Router# Show ip nat translations
Step 6 clear ssg open-garden Removes all instances of the ssg open-garden command
from the configuration and removes the service object of all
the open garden services.
Example:
Router# clear ssg open-garden
Step 7 clear ssg service profile-name Removes the service from SSG.
• For authenticated services, this command clears all of
Example: the connections (that is, users) logged into that service.
Router# clear ssg service profile-name

78-17497-01 189

Step 8 show ssg pass-through-filter [begin expression | (Optional) Displays the downloaded filter for transparent
exclude expression | include expression] pass-through.
Example:
Step 9 clear ssg pass-through-filter (Optional) Removes the downloaded filter for transparent
pass-through.
Example:
Router# clear ssg pass-through-filter
Troubleshooting SSG Support for Services

Perform this task to troubleshoot SSG support for services.
SUMMARY STEPS

4. debug ssg events
5. debug ssg errors
DETAILED STEPS

Step 1 debug ssg ctrl-events Displays event messages for the control modules, which
include all modules that manage the user authentication and
service logon and logoff (RADIUS, PPP, Subblock, and
Example:
Accounting).
• An event message is an informational message
generated during normal execution.
Step 2 debug ssg ctrl-errors Shows error messages for the control modules. These
modules include all those that manage the user
authentication and service logon and logoff (RADIUS, PPP,
Example:
Subblock, and Accounting).
• An error message is the result of an error detected
during normal execution.
Step 3 debug ssg ctrl-packets Shows packet messages for the control modules. These
modules include all those that manage the user
authentication and service logon and logoff (RADIUS, PPP,
Example:
Subblock, and Accounting).
• A packet message displays the contents of a package.

190 78-17497-01
Configuration Examples for SSG Support for Subscriber Services

Step 4 debug ssg events Displays event messages for the system modules such as
Timeout and Initialization.
Example: • An event message is an informational message that
Router# debug ssg events appears during normal execution.
Step 5 debug ssg errors Displays error messages for the system modules such as
Timeout and Initialization.
Example: • An error message is the result of an error detected
Router# debug ssg errors during normal execution.
Configuration Examples for SSG Support for Subscriber

Services
• Service Profile Configuration: Examples, page 191
• SSG Support for L2TP Tunnel Services: Examples, page 192
• SSG Support for L2TP Dial-Out Services: Examples, page 193
• SSG Open Garden Services: Example, page 202
• SSG Transparent Pass-Through: Example, page 202
Service Profile Configuration: Examples

Service Profile Configured on the AAA Server: Example
The following is an example of a service profile configured on the AAA server. The profile is formatted
for use with a freeware RADIUS server:
service1.com Password = "cisco", Service-Type = outbound,
Idle-Timeout = 1800,
Service-Info = "R192.168.1.128;255.255.255.192",
Service-Info = "R192.168.2.0;255.255.255.192",
Service-Info = "R192.168.3.0;255.255.255.0",
Service-Info = "Gservice1",
Service-Info = "D192.168.2.81",
Service-Info = "MC",
Service-Info = "TP",
Service-Info = "ICompany Intranet Access",
Service-Info = "Oservice1.com"
Service Profile Configured Locally on the Router: Example

The following example shows the configuration of a service profile locally on the router. This service
profile is configured to support an L2TP service.
ssg enable
!
local-profile l2tpnet1
attribute 26 9 251 "R0.0.0.0;0.0.0.0;I"
attribute 26 9 251 "TT"

78-17497-01 191
attribute 26 9 1 "vpdn:l2tp-tunnel-password=cisco"
attribute 26 9 1 "vpdn:ip-addresses=171.69.255.246"
attribute 26 9 1 "vpdn:tunnel-id=LAC18"
!
SSG Support for L2TP Tunnel Services: Examples

The following examples show how to configure SSG for L2TP services:
• LAC Configuration: Example
• RADIUS Service Profile: Example
• LNS Configuration: Example
LAC Configuration: Example

The following example shows how to configure the LAC:
vpdn enable
! “ip nat inside” command should be enabled on the downlink interface.
!
interface eth1/0
ip address 10.1.1.1 255.255.255.0
ip nat inside
}
RADIUS Service Profile: Example

The following example shows a basic RADIUS service profile for SSG support of L2TP:
reply_attributes= {
9,251="R10.6.6.0;255.255.255.0"
9,251="ODomain.com"
9,251="D10.7.7.7;10.7.7.8"
9,251="ITunnel1"
9,251="TT"
9,251="B1450"
9,1="vpdn:ip-addresses=10.8.8.8"
9,1="vpdn:tunnel-id=My-Tunnel"
9,1="vpdn:l2tp-tunnel-password=cisco"
LNS Configuration: Example

The following example shows a basic LNS configuration:
username l2tp_user password 0 cisco
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
terminate-from hostname My-Tunnel
l2tp tunnel password 7 02050D480809
!
ip local pool pool2 10.8.8.1 10.8.8.127
ip unnumbered FastEthernet0/0
no ip directed-broadcast
peer default ip address pool pool2

192 78-17497-01
SSG Support for L2TP Dial-Out Services: Examples

• Configuring SSG L2TP Dial-Out for SSG Without SSG Auto-Domain Enabled: Example, page 193
• Configuring SSG L2TP Dial-Out for SSG with SSG Auto-Domain Enabled: Example, page 195
• Configuring SSG L2TP Dial-Out User-Specific Configurations on the SOHO: Example, page 196
• Configuring a Large-Scale SSG L2TP Dial-Out Solution: Example, page 197
• Configuring a Global Dial-Out Service Profile: Example, page 199
• Configuring the Service Profiles for SSG L2TP Dial-Out: Example, page 200
• Configuring the Service Profile to Send MSISDN Data: Example, page 200
• Configuring a DNIS Filter: Example, page 200
Configuring SSG L2TP Dial-Out for SSG Without SSG Auto-Domain Enabled: Example
The following example shows the minimum configurations needed for an SSG L2TP Dial-Out solution
with the auto-domain feature disabled. Figure 5 illustrates a sample SSG L2TP Dial-Out network.
Figure 18 Sample SSG L2TP Dial-Out Network
AAA/SESM
ATM3/0 ATM1/0 S4/0
75760
SSG LAC SOHO
Subscriber
In this configuration, the SSG user can access the SOHO in two ways, with an account logon and then a
service logon or with an account logon with service configured as an autologon service.
User Profile Configurations: Examples

Use the following profile configuration when the SSG user accesses the SOHO with an account logon
and then a service logon:
user=abc {
check_items= {
2=cisco
}
reply_attributes= {
9,250-”Nsoho0”
}
}
}
with service configured as an autologon service:
user=abc {
radius-6510-SSG-v1.1 {

78-17497-01 193
check_items= {
2=cisco
}
reply_attributes= {
9,250-”Asoho0;user@DNIS;cisco”
}
}
}
Service Profile Configuration: Example

The following example shows how to configure the service profile:
user=soho0 {
check_items= {
2=cisco
}
reply_attributes= {
9,251= “TT”
9,251=”R172.0.0.1:255.0.0.0” ! This is the service network.
9,1=”vpdn:ip-address=66.102.0.1”
9,1=”vpdn:l2tp-tunnel-password=lab:
9,1=-”vpdn:tunnel-type=l2tp”
9,1=”vpdn:tunnel-id=lns_l2x0”
9,1=”vpdn:dout-type=2”
SSG Configuration: Example

SSG configuration includes enabling VPDN and configuring NAT on the downlink interface. The
following example shows how to perform the minimum complete configuration of SSG:
hostname SSG
aaa new-model
!
ip cef
! enable vpdn for l2tp dialout
vpdn enable
!
ssg enable
ssg service-password cisco
ssg bind direction downlink ATM3/0.1
!
interface ATM1/0.1 point-to-point ! For an IP user.
ip address 172.16.0.0 255.0.0.0
! enable NAT on the downlink interface
ip nat inside
pvc 0/33
!
interface ATM3/0.10 point-to-point ! For a PPP user.
pvc 0/100
encapsulation aal5mux ppp Virtual-Template1
!
ip unnumbered Ethernet2/2
peer default ip address pool ppp_pool_1
ppp authentication pap
ip nat inside
!
ip local pool ppp_pool_1 10.0.0.1 10.0.0.255
!

194 78-17497-01
radius-server host 10.2.36.253 auth-port 1645 acct-port 1646 timeout 5

radius-server key ssg

hostname LAC
!enable VPDN
vpdn enable
! enable to accept dialout tunnel
vpdn-group 1
accept-dialout
protocol l2tp
dialer 0 ! Matches rotary group and the dialer interface.
terminate-from hostname lns_l2x0
l2tp tunnel password 7 abcdef
!
idsn switch-type primary-5ess
!
interface Dialer0 ! All users coming to VPDN-group 0 are handled by this interface.
no ip address
encapsulation ppp
dialer in-band
dialer aaa
!
dialer-list 1 protocol ip permit
SOHO Configuration: Example

hostname soho0
username john password 0 cisco
!
controller T1 1/0
framing esf
linecode b8zs
pri-group timeslots 1-24
!
interface Serial1/0:23
no ip address
encapsulation ppp
dialer rotary-group 0 ! This matches the interface Dialer0.
isdn switch-type primary-5ess
no peer default ip address
no cdp enable
!
interface Dialer0
encapsulation ppp
dialer-group 1
peer default ip address pool soho_1
no cdp enable
ppp authentication chap
!
ip local pool soho_1 10.0.0.20 10.0.0.40
Configuring SSG L2TP Dial-Out for SSG with SSG Auto-Domain Enabled: Example
The following example shows the minimum configurations needed for an SSG L2TP Dial-Out solution
for an SSG with auto-domain enabled, one LAC and one SOHO.

78-17497-01 195
In this configuration, the SSG user is assumed to access the SOHO with an account login and then a
service login with “user@dnis” as the username. In this solution, services are selected on the basis of
auto-domain configuration (basic or extended mode) and the global service configured for the SSG
dial-out.
User Profile Configuration: Example

with “user@dnis” as the username:
user=soho1{
radius=6510-SSG-v1.1{
check_items= {
2=cisco
}
reply_attributes={
9,250=”Asoho0”
9,250-”Npassthru1”
}
}
}

.
.
.
!
ssg dial-out
dnis-prefix all service soho1 ! This indicates SSG Autodomain in extended mode.
or
dnis-prefix all service soho0 ! This indicates SSG Autodomain in basic mode.
.
.
.
LAC and SOHO Configurations

The LAC and SOHO configurations for SSG with SSG Auto-domain configured are the same as the
configuration for SSG without SSG Auto-domain configured. See the “Configuring SSG L2TP Dial-Out
for SSG Without SSG Auto-Domain Enabled: Example” section on page 193 for more details.
Configuring SSG L2TP Dial-Out User-Specific Configurations on the SOHO: Example

The following example shows how to configure user-specific configurations on the SOHO. The user
profile, service profile, SSG, and LAC configurations are the same as in the “Configuring SSG L2TP
Dial-Out for SSG Without SSG Auto-Domain Enabled: Example” section on page 193.
hostname soho0
username user1 password 0 cisco
username user1@4444007 password 0 cisco
username user7 password cisco
!
controller t1 1/0
framing esf
linecode b8zs
!
interface serial1/1:23
no ip address
encapsulation ppp

196 78-17497-01
dialer pool-member 1
no peer default ip address
no cdp enable
!
interface Dialer1 ! Configures a special service policy and pool for user “user1.”
ip unnumbered loopback1
encapsulation ppp
dialer pool 1
dialer remote-name john
dialer idle-timeout 2147483
dialer string 3456048
dialer-group 1
service-policy output SETDSCP
peer default ip address pool soho_1
!
interface Dialer2 ! Configures a special service policy and pool for user “user7.”
ip unnumbered loopback1
encapsulation ppp
dialer pool 1
dialer remote-name gary
dialer idle-timeout 2147483
dialer-group 1
peer default ip address pool soho_OLAPP
pulse-time 0
!
ip local pool soho_1 10.0.0.20 10.0.0.40
ip local pool soho_OLAP 11.0.0.10
Configuring a Large-Scale SSG L2TP Dial-Out Solution: Example

The following example shows how to configure an SSG L2TP Dial-Out solution with multiple LACs and
multiple SOHOs. Figure 6 shows a sample large-scale SSG L2TP Dial-Out network.
Figure 19 Sample Large-Scale SSG L2TP Dial-Out Network
AAA/SESM
SSG1 LAC10 SOHO10
Subscriber
SOHO20
75761
LAC11 SOHO11

78-17497-01 197
User Profile Configuration: Example

The user profile configuration is the same as that shown in the “Configuring SSG L2TP Dial-Out for
SSG Without SSG Auto-Domain Enabled: Example” section on page 193.
Service Profile Configuration: Example

SSG selects the LAC to which it will create a tunnel by looking at the service profile. In the following
example, the IP addresses configured in the LAC interfaces to SSG are
• LAC10 = 172.16.0.0
• LAC11 = 172.17.0.0
user = soho10{
check_items= {
2=cisco
}
reply_attributes= {
9,251="TT”
9,251="R170.0.0.1;255.0.0.0"
9,1="vpdn:ip-addresses=172.16.0.0" ! IP address of LAC10.
9,1="vpdn:l2tp-tunnel-password=lab"
9,1="vpdn:tunnel-type=l2tp"
9,1="vpdn:tunnel-id=lns_l2x0"
9,1="vpdn:dout-type=2"
}
}
}
user = soho11{
check_items= {
2=cisco
}
reply_attributes= {
9,251="TT"
9,251="R170.0.0.1;255.0.0.0"
9,1="vpdn:ip-addresses=172.17.0.0" ! IP address of LAC11.
9,1="vpdn:l2tp-tunnel-password=lab"
9,1="vpdn:tunnel-type=l2tp"
9,1="vpdn:tunnel-id=lns_l2x0"
9,1="vpdn:dout-type=2"
}
}
}

The SSG Configuration for a large-scale SSG L2TP Dial-Out solution is the same as that in the
“Configuring SSG L2TP Dial-Out for SSG Without SSG Auto-Domain Enabled: Example” section on
page 193.

The following example shows a sample configuration for LAC10:
hostname LAC10
vpdn enable
!
vpdn-group 1
accept-dialout
protocol l2tp
dialer 0 ! This configuration matches with rotory-group and dialer interfaces.

198 78-17497-01
terminate-from hostname ForSoho10 ! This tunnel ID “ForSoho10” will be terminated.

l2tp tunnel password 7 060A0E23
!
vpdn-group 1
accept-dialout
protocol l2tp
dialer 1 ! To match with rotary-group and dialer interfaces.
terminate-from hostname ForSoho20 ! This tunnel ID “ForSoho20” will be terminated.
l2tp tunnel password 7 060A0E23
!

!
controller T1 4/0
framing esf
linecode b8zs
!
ip address 100.0.0.2 255.0.0.0
pvc 0/100
!
no ip address
encapsulation ppp
dialer rotary-group 0
dialer-group 1
!
interface Dialer0
no ip address
encapsulation ppp
dialer in-band
dialer aaa
!
no ip address
encapsulation ppp
dialer rotary-group 1
dialer-group 1
!
interface Dialer1
no ip address
encapsulation ppp
dialer in-band
dialer aaa
!
SOHO Configuration: Example

The SOHO configuration for a large-scale SSG L2TP dial-out solution is the same that as shown in the
“Configuring SSG L2TP Dial-Out for SSG Without SSG Auto-Domain Enabled: Example” section on
page 193.
Configuring a Global Dial-Out Service Profile: Example

The following example shows how to configure a global dial-out service profile called “dialout_1”:

78-17497-01 199
ssg dial-out
dnis-prefix all service dialout_1
Configuring the Service Profiles for SSG L2TP Dial-Out: Example

The following is an example of a service profile when SSG Auto-domain is configured in basic mode:
user = dialout_tunnel1{
member = SSG-DEV
radius = 6510-SSG-v1.1 {
check_items= {
2 = cisco
}
reply_attributes= {
9,251 = “TT”
9,251 = “R172.16.0.0;255.255.0.0;I”
9,1 = “vpdn:ip-addresses=10.0.0.1”
9,1 = “vpdn:l2tp-tunnel-password=cisco”
9,1 = “vpdn:tunnel-type = l2tp”
9,1 = “vpdn:tunnel-id = ssg1”
9,1 = “vpdn:dout-type=2”
Configuring the Service Profile to Send MSISDN Data: Example

The following example shows how to configure a service profile with the SSG service-info VSA to send
the MSISDN number along with the DNIS number while establishing the dial-out tunnel.
The attribute 9,251=“Y” sends the MSISDN number with the DNIS number. The character “#” (pound
sign) is the delimiter between the DNIS number and the MSISDN number.
user = dialout_tunnel{
member=SSG-DEV
radius=6510-SSG-v1.1{
check_items= {
2=cisco
}
reply_attributes= {
9,251=“TT”
9,251=“R172.16.0.0;255.255.0.0;I”
9,1=“vpdn:ip-addresses=10.0.0.0”
9,1=“vpdn:l2tp-tunnel-password=cisco”
9,1=“vpdn:tunnel-type=l2tp”
9,1=“vpdn:tunnel-id=ssg1”
9,1=“vpdn:dout-type:2”
9,251=“Y#” ! MSISDN/DNIS attribute
Configuring a DNIS Filter: Example

The following example shows how to configure a DNIS exclude profile in AAA:
user = exclude_dnis_aaa{
member = SSG-DEV
check_items= {
2=cisco
}
reply_attributes= {
9,253="XD+444"
9,253="XD22222T"
}

200 78-17497-01
}
}
The following example shows how to add two DNIS prefixes to the exclude profile and to download a
DNIS exclude profile named “exclude_dnis_aaa” with a password of “cisco”:
ssg dial-out
exclude dnis-prefix 18085288110
exclude dnis-prefix 18085288111
download exclude-profile exclude_dnis_aaa cisco
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”.
ssg bind service sample-service atm 1/0.1
ssg bind service sample-service atm 1/0.2 100
!
ip address 10.1.0.1 255.255.0.0
!
ip address 10.2.0.1 255.255.0.0
!
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”).
!
ssg bind service sample-serviceA 10.1.1.1
!
ip address 10.0.1.1 255.255.255.0
!
ip address 10.0.2.1 255.255.255.0
!
ip route 10.1.1.1 255.255.255.255 eth 1/0 10
ip route 10.1.1.1 255.255.255.255 eth 2/0 20

78-17497-01 201
Service Bound to Multiple Next Hops Through Same Uplink Interface: Example
In the following example, a service called “sample-serviceA” is bound to primary next-hop gateway
10.1.1.1 (with distance-metric = 10) and secondary next-hop gateway 10.2.2.2 (with distance-metric =
20). Both of the next-hop gateways are reachable through the same uplink interface: Ethernet interface
1/0.
!
ssg bind service sample-serviceA 10.1.1.1 10
ssg bind service sample-serviceA 10.2.2.2 20
!
description connected to 10.0.0.2
ip address 10.0.0.1 255.255.255.0
ssg direction uplink
!
ip route 10.1.1.1 255.255.255.255 10.0.0.2
ip route 10.2.2.2 255.255.255.255 10.0.0.2
SSG Open Garden Services: Example

In the following example, two services, called “og1” and “og2”, are defined and added to the open
garden.
local-profile og1
attribute 26 9 251 "Oopengarden1.com"
attribute 26 9 251 "D10.13.1.5"
attribute 26 9 251 "R10.1.1.0;255.255.255.0"
local-profile og2
attribute 26 9 251 "Oopengarden2.com"
attribute 26 9 251 "D10.14.1.5"
attribute 26 9 251 "R10.2.1.0;255.255.255.0"
attribute 26 9 251 "R10.3.1.0;255.255.255.0"
!
ssg bind service og2 10.5.5.1
!
ssg open-garden og1
ssg open-garden ot2
!
SSG Transparent Pass-Through: Example

The following example shows how to enable SSG transparent pass-through and download a pass-through
filter from the AAA server called “filter01”:
ssg pass-through
ssg pass-through filter download filter01 cisco
Radius reply received:

Created Upstream acl from it.
Created Downstream acl from it.
Loading default pass-through filter succeeded.
The following example shows how to enable SSG transparent pass-through and apply ACLs with it. The
ACLs are defined on the router, which allows traffic from 10.0.0.1/32 (an SNMP tool kept on the
downlink).
access-list 101 remark for upstream traffic
access-list 101 permit ip host 10.0.0.1 any

202 78-17497-01
access-list 102 remark for downstream traffic

access-list 102 permit ip any host 10.0.0.1
ssg pass-through filter 101 uplink

ssg pass-through filter 102 downlink
The following sections provide references related to the Configuring SSG for Subscruber Services
features.
Related Documents
Release 12.4
Description Link
even more content.
Feature Information for SSG Subscriber Services

table.

78-17497-01 203
Table 1 Feature Information for SSG Subscriber Services

SSG L2TP Dial-Out 12.2(15)B The L2TP Dial-Out feature provides mobile users with a
12.2T way to securely connect to their SOHOs through the PSTN.
12.3(4)T The following sections provide information about this
12.4 feature:
• Configuring SSG to Support L2TP Dial-Out Services,
page 177
dnis-prefix all service, ssg dial-out.
SSG Open Garden 12.1(5)DC The SSG Open Garden feature enables you to use Cisco
12.2(4)B SSG to implement open gardens, which are collections of
12.2(8)T Web sites or networks that subscribers can access as long as
12.2(11)T they have physical access to the network. Subscribers do not
12.2(13)T have to provide authentication information before accessing
12.4 the Web sites in an open garden.
feature:
• Open Garden (Unauthenticated) Services, page 165
• Configuring SSG Open Garden Services, page 186
The following commands were introduced or modified by
this feature: clear ssg open-garden, local-profile, show ssg
open-garden, ssg open-garden.

204 78-17497-01
Table 1 Feature Information for SSG Subscriber Services (continued)

SSG Service Logon Enhancements 12.2T The SSG Service Logon Enhancements feature enables SSG
12.3(7)T to deliver services to a subscriber after receiving valid
authentication information.
feature:
• Authenticated Services, page 162
SSG Service Profile Caching 12.2T The Service Profile Cache feature enables SSG to use a
12.3(4)T cached copy of a service profile instead of downloading the
profile from a RADIUS server every time a user logs on to
the service.
feature:
• Service Profile Caching, page 170

78-17497-01 205

206 78-17497-01
Configuring SSG Subscriber Experience
Features
First Published: May 1, 2005

Last Updated: April 17, 2006
This chapter provides information about configuring the following Service Selection Gateway (SSG)
subscriber experience features:
• Hierarchical Policing
• TCP Redirection
• Per-Session Firewall
• DNS Redirection

Your Cisco IOS software release may not support all of the features documented in this module. To reach
links to specific feature documentation in this module and to see a list of the releases in which each feature is
supported, use the “Feature Information for Configuring SSG Subscriber Experience Features” section
on page 257.
Finding Support Information for Platforms and Cisco IOS Software Images
Contents
• Prerequisites for Configuring SSG Subscriber Experience Features, page 208
• Information About SSG Subscriber Experience Features, page 208
• How to Configure SSG Subscriber Experience Features, page 224
• Configuration Examples for Configuring SSG Subscriber Experience Features, page 250
• Additional References Related to SSG Subscriber Experience Features, page 255
• Feature Information for Configuring SSG Subscriber Experience Features, page 256

78-17497-01 207
Configuring SSG Subscriber Experience Features
Prerequisites for Configuring SSG Subscriber Experience Features
Prerequisites for Configuring SSG Subscriber Experience

Features
Before you can perform the tasks in this process, you must enable SSG. To enable SSG, see "Enabling
SSG," in the"Implementing SSG: Initial Tasks" section.
Information About SSG Subscriber Experience Features

With SSG subscriber experience features, an internet service provider (ISP) can configure SSG features
to suit individual user preferences and to control the user experience for its subscribers.
For example, SSG allows users to choose multiple services that have their own specific bandwidth
requirements (such as an ISP’s regular service or a premium service). To ensure that the bandwidth is
distributed properly for customers who use different types of services, SSG uses traffic policing.
Furthermore, because the bandwidth can be first policed between users, and then policed again between
the services to a particular user (a hierarchical policing technique), SSG provides the SSG Hierarchical
Policing feature, which can be configured to suit particular user requirements.
The SSG Hierarchical Policing feature is just one of the SSG subscriber experience features described
in this chapter. The remainder of this chapter provides all the information required to configure SSG
subscriber experience features, based on user preferences.
This section provides conceptual information and restrictions that may apply to specific SSG subscriber
experience features.
For detailed information about configuring SSG subscriber experience features, see How to Configure
SSG Subscriber Experience Features, page 224.
Before you configure SSG subscriber experience features, review and understand the SSG concepts
provided in the following sections:
• SSG Hierarchical Policing Overview, page 209
• SSG TCP Redirect Features Overview, page 213
• Per-Session Firewall Overview, page 220
• Default DNS Redirection Overview, page 222

208 78-17497-01
SSG Hierarchical Policing Overview

SSG allows subscribers to choose one or more types of services. Each type of service has its own
bandwidth requirements; for example, suppose an ISP has two types of services, regular and premium.
The regular service is cheaper for customers but is allocated less bandwidth per customer than the
premium service, which provides more bandwidth and a higher quality connection than the regular
service. SSG, therefore, requires a mechanism to ensure that bandwidth is distributed properly for
customers using different types of services.
The following sections explain the concepts of hierarchical policing:
• SSG Per-User and Per-Session Policing, page 209
• SSG Hierarchical Policing Token Bucket Scheme, page 210
For detailed information about configuring SSG hierarchical policing, see Configuring SSG Hierarchical
Policing, page 224.
SSG Per-User and Per-Session Policing

Traffic policing is the concept of limiting the transmission rate of traffic entering or leaving a node. In
SSG, traffic policing can be used to allocate bandwidth between subscribers and between services to a
particular subscriber to ensure that all types of services are allocated a proper amount of bandwidth. SSG
uses per-user and per-session policing to ensure that bandwidth is distributed properly between
subscribers (per-user policing) and between services to a particular subscriber (per-session policing).
Because these policing techniques are hierarchical in nature (bandwidth can be first policed between
users and then policed again between services to a particular user), this complete feature is called SSG
Hierarchical Policing.
• Per-user policing:
– is used to police the aggregated traffic that is destined to or that is sent from a particular
subscriber and can police only the bandwidth allocated to a subscriber.
– cannot identify services to a particular subscriber and police bandwidth between these services.
• Per-session policing:
– is used to police the types of services available to a subscriber.
– provides a mechanism for identifying the types of services (such as video service or Internet
access in the example) and ensuring that users do not exceed the allocated bandwidth for the
service.
– is useful when an SSG subscriber subscribes to more than one service, and multiple services are
allocated different amounts of bandwidth; for example, suppose a single subscriber pays
separately for Internet access and video service but receives both services from the same service
provider. The video service is allocated more bandwidth than the Internet access service and
costs more to the subscriber.

78-17497-01 209
SSG Hierarchical Policing Token Bucket Scheme

The SSG Hierarchical Policing token bucket scheme polices the use of bandwidth through an algorithm.
The parameters used by the algorithm to allocate bandwidth are user configurable; however, other
unpredictable variables, such as time between packets and packet sizes, ultimately determine whether a
packet is transmitted or dropped.
The following sections explain the aspects of the SSG Hierarchical Policing token bucket scheme:
• Committed Rate, Normal Burst, and Excess Burst
• Actual and Compound Debt
• Token Bucket Algorithm Calculations
Committed Rate, Normal Burst, and Excess Burst
The SSG Hierarchical Policing feature limits the transmission rate of traffic based on a token bucket
algorithm that analyzes a packet and determines whether the packet should be forwarded to its
destination or dropped. A token bucket can be used to monitor upstream traffic (traffic sent by a
subscriber) or downstream traffic (traffic destined for a subscriber), and a bucket can be configured in
both directions for a user or a service profile.
As shown in Table 2, the committed rate, normal burst, and excess-burst are the user-configurable
parameters when configuring SSG Hierarchical Policing. These parameters are used by the SSG
Hierarchical Policing token buckets to evaluate traffic.
Table 2 SSG Hierarchical Policing User-Configurable Parameters
Parameter Purpose
committed-rate The committed-rate parameter is the amount of bandwidth that is
entitled to a subscriber (per-user policing) or to a service for a
particular subscriber (per-session policing). The token bucket
algorithm uses the committed-rate parameter for generating tokens
when a packet arrives.
The committed-rate parameter is equal to the minimum amount of
bandwidth that is guaranteed to a subscriber or service.
Note The committed rate is specified in bits per second, while the
normal burst and excess-burst sizes are specified in bytes.

210 78-17497-01
Table 2 SSG Hierarchical Policing User-Configurable Parameters (continued)
Parameter Purpose
normal-burst The normal-burst parameter determines the maximum size of a traffic
burst before packets are dropped.
excess-burst The excess-burst size parameter is an optional variable that
determines the burst size beyond which all traffic is dropped. The
excess-burst size parameter is disabled when it is set lower than the
normal burst size.
If the excess-burst size parameter is configured, the traffic that falls
between the normal-burst size and the excess-burst sizes is dropped
based on a calculated probability (the probability that traffic will be
forwarded increases as the size of the configured excess-burst
parameter increases).
If a token bucket is configured with an excess-burst size, subscribers
and services using additional bandwidth will likely experience
sporadic drops (similar to the method in which packets are dropped by
using the Random Early Detection [RED] feature).
Actual and Compound Debt
Before explaining the calculations used by the token bucket algorithm to drop or forward packets, an
understanding of actual and compound debt is useful.
When a normal or excess-burst is required to forward traffic, debt is incurred. The debt is then compared
to the configured parameters, and the algorithm either sends or drops the packet based on the
comparison.
The probability for the algorithm to forward large packets increases when a user or a service has been
idle for a long period of time.

78-17497-01 211
Table 3 provides a definition of actual and compound debt:

Table 3 Actual and Compound Debt Definitions
Term Definition
actual debt The actual debt is the number of tokens that have been borrowed by
the current packet.
When a packet is forwarded by using a burst, the actual debt is
compared to the user-configured normal-burst size. If the actual debt
is less than the normal-burst size, the packet is forwarded. If the actual
debt is greater than the normal-burst size, the packet is either dropped
(excess-burst configuration is less than the normal-burst size) or
forwarded by using the excess-burst size (which is possible when the
excess-burst size is larger than the normal-burst size).
compound debt The compound debt is equal to the total number of tokens that have
been borrowed—in addition to the normal-burst allowance. Because
additional tokens cannot be borrowed when the excess-burst
parameter is not set, compound debt is only used when the
excess-burst parameter is set.
Compound debt is only a factor in forwarding a packet after the actual
debt exceeds the normal-burst size.
Compound debt is compared to the excess-burst size. If the compound
debt is less than the excess-burst size, the packet is forwarded. If the
compound debt is greater than the excess-burst size, the packet is
dropped.
Token Bucket Algorithm Calculations
The following steps describe how the algorithm that polices traffic operates:
1. The packet arrives. The packet size (Ps) is noted.
2. The time between the arrival of the last packet and the arrival of the current packet is calculated.
This calculation is called time difference (td).
3. The actual debt is calculated and is based on the following formula:
actual_debt = previous_actual_debt (Ad) + Ps
4. The tokens that can be generated by the arriving packet are calculated:
tokens = committed_rate (Ar) * td
5. The tokens are then compared to the actual debt.
a. If tokens > actual_debt, the actual debt for the packet is set at 0.
b. If tokens < actual debt, the actual debt is calculated by using the following formula:
actual_debt = actual_debt – tokens
6. The actual debt is compared to the normal burst to see if traffic should be forwarded or dropped.
a. If actual_debt < normal_burst, the packet conforms and is forwarded.
b. If actual_debt > normal_burst, the packet is dropped if the excess-burst size is not configured.
If actual_debt > normal_burst and the excess-burst size is configured, compound debt is
checked.

212 78-17497-01
c. The compound debt is calculated by using the following formula:

compound_debt = previous_compound_debt + (actual_debt – normal_burst)
d. If compound_debt < excess_burst, the packet is forwarded.
e. If compound_debt > excess_burst, the packet is dropped.
SSG TCP Redirect Features Overview

The SSG TCP Redirect function includes a suite of features that are described in the following sections:
• SSG TCP Redirect for Services Overview, page 213
• SSG TCP Redirect for Unauthenticated Users, page 213
• SSG TCP Redirect for Unauthorized Services, page 214
• SSG TCP Redirect Initial Captivation, page 215
• SSG TCP Redirect Access Control Lists Overview, page 216
• SSG Permanent TCP Redirection Overview, page 217
For detailed information about configuring TCP Redirect features, see Configuring SSG TCP
Redirection Features, page 229.
SSG TCP Redirect for Services Overview

The SSG TCP Redirect for Services feature redirects certain packets, which would otherwise be
dropped, to captive portals that can handle the packets in a suitable manner. For example, packets sent
upstream by unauthorized users are forwarded to a captive portal that can redirect the users to a login
window. Similarly, if users try to access a service to which they have not logged in, the packets are
redirected to a captive portal that can provide a service login window.
The captive portal can be any server that is programmed to respond to the redirected packets. If the Cisco
Subscriber Edge Services Manager (SESM) is used as a captive portal, unauthenticated subscribers can
be sent automatically to the SESM login window when they start a browser session. In SESM Release
3.1(3), captive portal applications can also redirect users to a service login window, advertising pages,
and message pages. The SESM captive portal application can also capture a URL in a subscriber’s
request and redirect the browser to the originally requested URL after successful authentication.
Redirected packets are always sent to a captive portal group that consists of one or more servers. SSG
selects one server from the group in a round-robin fashion to receive the redirected packets.
SSG TCP Redirect for Unauthenticated Users

The SSG TCP Redirect for Unauthenticated Users feature redirects packets from a user if the user has
not been authorized by the service provider. When an unauthorized subscriber attempts to connect to a
service on a TCP port (for example, to www.cisco.com), the SSG TCP Redirect feature redirects the
packet to the captive portal (SESM or a group of SESM devices). SESM issues a redirect to the browser
to display the login window. The subscriber logs in to SESM and is authenticated and authorized. SESM
then presents the subscriber with a personalized home page, the service provider home page, or the
original URL.
The SSG TCP Redirect for Services feature always sends redirected packets to a captive portal group
that consists of one or more servers. SSG selects one server from the group in a round-robin fashion to
receive the redirected packets. For upstream packets, SSG modifies the destination IP address and TCP
port to reflect the destination captive portal. For downstream packets, SSG returns the source IP address

78-17497-01 213
and port to the original packet’s destination. SSG uses the same redirect server if multiple TCP sessions
from the same user are redirected. When the TCP session terminates or is idle for more than 60 seconds,
SSG clears translations of packets made before the packets are sent to the captive portal. In host-key
mode with overlapping user IP addresses, redirection works only for host-keyed servers.
Note This feature applies only to non-PPP users. PPP users are always authenticated as part of the
PPP negotiation process. PPP users logging off from SESM are also redirected.
The following describes the behavior of redirection for unauthorized users:

• If a user is subject to redirection or captivation, then packets from the user that match the protocol
and ports configured as the redirection and captivation filter are sent to SESM. If the user packet
does not match the filter, SSG drops the packet.
• SSG drops all packets to the user, unless the packet arrives from the SESM or the Open Garden
network.
SSG TCP Redirect for Unauthorized Services

The Redirect for Unauthorized Services feature redirects TCP sessions from authenticated users who
have not been authorized to access service networks. SSG TCP Redirect redirects the packets to a captive
portal, such as SESM, which then prompta the user to log in.
SSG can redirect unauthorized TCP sessions for different networks to different servers. For
network-based redirection, a list of networks are used for unauthorized service redirect. The network list
is associated with a group of servers. Only one network list can be associated with a server group.
The server group can also be associated with a port or a list of ports. Servers handle particular captive
portal applications as defined by the port that they use. TCP sessions redirected to servers can be
restricted based on a port or port list. A port list defines a named list of interesting destination TCP ports.
The port list is associated with a server group and is used to restrict the applications redirected to a server
group. Only one port list or port can be associated with a server group.
If none of the destination networks matches the networks in the network list, you can set up a default
server group to receive redirected packets by using the redirect unauthorized-service command.
[no] redirect unauthorized-service [destination network-list network-listname] to
group-name
SSG TCP Redirect also restricts access to certain networks that are part of another authorized service.
For example, in Figure 20 the user is allowed to access ServiceA. IPTVService is part of ServiceA, but
the user is not authorized to access IPTVService. SSG redirects TCP sessions from the user to
IPTVService (10.1.1.1/32), but allows access to anywhere else in ServiceA (10.0.0.0/8).
Figure 20 Restricting Access to Networks Within Authorized Services
ServiceA
10.0.0.0/8
87908
IPTVService 10.1.1.1/32

214 78-17497-01
The following describes the behavior of redirection for unauthorized services:

• If a packet arrives from an unauthorized SSG user or a packet is destined to an unauthorized service,
SSG redirects the packet if the packet matches the protocol and ports configured as the redirection
filter. If the packet does not match the filter, SSG drops the packet.
• If a packet arrives from an unauthorized service or is destined to an unauthorized SSG user,
SSG drops the packet.
• If a user’s connection is subject to redirection or captivation, any packets from the connection that
match the protocol and ports for redirection and captivation are redirected to SESM by SSG.
• If packets from the connection do not match the protocol and ports configured as a filter, SSG drops
the packets.
SSG TCP Redirect Initial Captivation

The SSG TCP Redirect Initial Captivation feature redirects certain packets from users for a specific
period of time. After a user logs in, packets to certain TCP ports are redirected to a server for
advertisements and branding. The initial captivation feature redirects all user packets to those TCP ports
regardless of the destination address, and is active for a specified duration, starting from the first
redirected session.
If you configure the initial captivation feature globally by using the CLI, the confiuration applies to all
authenticated users. You can also enable the initial captivation feature in the RADIUS user profile as an
Account-Info attribute to override the CLI setting.
The user profile contains the following information for initial captivation:
• Server group name
Note Use the CLI to configure the server group and to associate a port or port list to the server
group.
• Duration of captivation
• Service name (optional)
Note If you specify the optional service name, captivation is activated only when a user logs in to
that service.
Typically, if a service is connected, SSG forwards packets to a user and packets from a user even if the
packets do not match the protocol and TCP ports that are specified for redirection. However, the behavior
of initial captivation on the Cisco 10000 series router differs in the following ways:
• When a packet arrives from an SSG user and the packet matches the protocol and TCP ports
configured as the redirection filter, the packet is subject to initial captivation and is redirected. If the
packet does not match the redirection filter, it is not subject to initial captivation and the packet is
dropped.
• When a packet arrives from a service destined for an SSG user who is subject to initial captivation,
the packet is dropped.

78-17497-01 215
SSG TCP Redirect Access Control Lists Overview

SSG TCP redirect functionality allows SSG to redirect TCP packets from users on the basis of the
destination port number. The SSG TCP Redirect Access Control Lists feature enables SSG to use
Cisco IOS software access control lists (ACLs or access lists) to select Internet traffic for redirection.
An ACL is associated with a TCP redirect server group. A TCP packet from a subscriber is redirected to
a server in that group only if permitted by the access list for that group. This functionality can be used
for all types of redirections: unauthenticated users, unauthorized service, initial and periodic captivation,
prepaid redirection on quota expiry, and Simple Mail Transfer Protocol (SMTP) forwarding.
An ACL:
• is an additional,optional criterion for selecting packets for redirection.
• makes a port or port list optional.
– If a port list is also associated with a server group, the TCP packet must match the ACL and port
list.
– Only one ACL can be associated with a server group.
Either an ACL, or a port or port list should be configured with server groups for unauthorized
service redirection and captivation. The ACL can be simple or extended, and can also be named
or numbered.
SSG provides an option to configure a default ACL for TCP redirections. This default is used with server
groups that do not have a configured ACL.
This section describes the following SSG TCP Redirect ACL concepts:
• Uses for SSG TCP Redirect Access Control Lists, page 216
• Prevention of Redirection of Non-HTTP Applications, page 216
• Location-Based Redirections, page 217
• Redirection to a Service Network for Captivation, page 217
• Redirection for a Range of TCP Ports, page 217
For information about configuring SSG TCP redirect ACLs, see Associating an Access Control List with
a Redirection Group, page 234.
Uses for SSG TCP Redirect Access Control Lists
The SSG TCP Redirect Access Control Lists feature allows you to use access lists to select TCP traffic
sessions for redirection or to prevent certain TCP traffic sessions from being redirected.
The following are examples of possible uses of this feature.
Prevention of Redirection of Non-HTTP Applications
Ports or port lists can be used with the SSG TCP Redirect feature to control which applications are
redirected; however, some servers may provide non-HTTP application services on standard ports. The
TCP redirection servers may not be able to handle such applications. In these cases, ACLs can be used
to prevent redirection of TCP sessions to these types of application servers.

216 78-17497-01
Location-Based Redirections
SSG TCP redirect ACLs can be used for location-based redirections. For example, a network might
include multiple SESMs, each of which is customized for a different location. SSG can be configured
with each SESM in a different TCP redirect group. Each TCP redirect group can be associated with an
ACL that permits a particular subnet of hosts from one location. The server groups can then be used for
location-based unauthenticated user or service redirections.
Redirection to a Service Network for Captivation
For captivation redirections, the messaging portal is used to redirect browsers to a different URL on
advertising servers. When captivation is active and the advertising servers are outside the SSG default
network and open gardens, the TCP session to such servers is redirected back to the messaging portal,
resulting in a loop. The SSG TCP Redirect Access Control Lists feature can be used to prevent
redirection of traffic to advertisement servers for captivation.
Redirection for a Range of TCP Ports
Cisco IOS software extended ACLs provide the option to configure a range of ports in an ACL entry.
Extended ACLs can be used with the SSG TCP Redirect feature for redirection on the basis of a range
of ports, without having to enter all the ports in the range into a port list.
SSG Permanent TCP Redirection Overview

The SSG Permanent TCP Redirection feature enables Service Selection Gateway (SSG), with Cisco
Subscriber Edge Services Manager (SESM), to provide service selection support to users whose web
browsers are configured with HTTP proxy servers. This feature supports plug-and-play functionality in
public wireless LANs.
This section describes the following SSG Permanent TCP Redirection concepts:
• How SSG Permanent TCP Redirection Works
• Supported SSG Permanent TCP Redirection Functionality
• RADIUS Attributes for SSG Permanent TCP Redirection
How SSG Permanent TCP Redirection Works
An HTTP-proxy server is a server that acts like an HTTP (or web) server for the user, but is just a proxy.
Browsers such as Netscape, Mozilla, and Windows Internet Explorer can be configured to send all HTTP
traffic to an HTTP proxy server, which brings back the web pages from the real HTTP server. In this
document, the term traffic refers to HTTP traffic from the HTTP proxy user, and the term user (or HTTP
proxy user) refers to a user with HTTP proxy settings in his or her browser (unless otherwise stated).
When an HTTP proxy server is configured in a browser, HTTP traffic is always directed to the HTTP
proxy server. HTTP proxy servers are usually internal to a corporate intranet or Internet service provider
(ISP) and are usually not routable globally.
If an HTTP proxy user attempts to open a web page from a public wireless LAN (PWLAN), SSG drops
the HTTP traffic because the HTTP server is not routable by SSG. The SSG Permanent TCP Redirection
feature enables SSG to support users whose web browsers are configured with HTTP proxy servers.
Figure 21 shows an example of a typical wireless LAN (WLAN) topology that uses permanent TCP
redirection.

78-17497-01 217
Figure 21 Sample WLAN Topology for SSG Permanent TCP Redirection
Cisco SESM AAA server
IP
network
Wireless Access Cisco SSG
access router
point
95811
The following steps provide a general description of how permanent TCP redirection works:
1. A user (IPu) enters a WLAN hot spot (a specific location in which an access point provides public
wireless broadband network services to mobile visitors) and opens the browser on his or her laptop.
The browser is configured with an HTTP-proxy server (IPw : Portw).
2. The user tries to open a web page; for example, http://www.example.com. The browser sends the
traffic to the HTTP proxy server (IPw : Portw).
3. SSG intercepts the traffic from unauthenticated user IPu and passes the traffic to the SESM captive
portal.
4. The SESM captive portal looks into the HTTP packet and determines if the packet is destined for
the HTTP proxy server. When the SESM captive portal determines that the packet is destined for an
HTTP proxy server, the SESM captive portal sends a message to SSG containing the user’s HTTP
proxy settings.
5. SSG stores the information (namely, that user IPu has the HTTP proxy server setting IPw : Portw).
From now on, SSG will redirect all traffic from user IPu and destined for IPw : Portw to the local
HTTP proxy server for unauthenticated users, which is running on SESM.
6. Once the user has been authenticated, SSG will redirect all traffic from the user IPu and destined for
IPw : Portw to the local HTTP proxy server for authenticated users, which is also running on SESM.
Supported SSG Permanent TCP Redirection Functionality
The SSG Permanent TCP Redirection feature supports the following functionality:
• SSG allows users with browsers that are configured with HTTP proxy servers to log in and connect
to the Internet. The HTTP proxy server can be configured as an IP address or a domain name.
• SSG supports users with HTTP proxy server configurations who also use Extensible Authentication
Protocol (EAP) authentication methods. SSG redirects the users to the SESM captive portal by using
the initial-captivation functionality.
• SSG supports users with HTTP proxy server configurations in PWLAN hot spots in which the hot
spot allows users to select from multiple ISPs. In such cases, each ISP must have an instance of the
HTTP proxy server running on SESM, and this instance can be defined in the ISP’s service profile.
ISPs can share the same HTTP server.
• SSG allows users to initiate an end-to-end Virtual Private Network (VPN) connection after users
have been authenticated and authorized to reach the Internet or VPN gateway.

218 78-17497-01
• If an authenticated user selects a corporate service (a Layer 2 Tunnel Protocol (L2TP) tunnel service
that is initiated from SSG), the service can be configured so that SSG allows HTTP traffic to reach
the service without redirecting it to the local HTTP proxy server.
Note The corporate HTTP proxy server must be able to reach SESM in order for users to be able
to log off or manage services. To enable HTTP proxy users to reach SESM, give SESM a
globally routable IP address.
• SSG permanent TCP redirection is supported with or without the SSG Port-Bundle Host Key
feature.
• SSG accounting includes all HTTP traffic going to the HTTP proxy server, including the traffic
destined for the open garden or TCP-redirect server (which is otherwise not included in the
accounting).
Note If you use the CSG as the authenticated HTTP server, you can configure the CSG to prevent
HTTP traffic destined for the open garden or TCP redirect server from being included in
accounting.
• The SSG Permanent TCP Redirection feature is supported, even if the user is configured with an
exclude list for the HTTP proxy server and the home page (or first page) falls into the exclude list.
RADIUS Attributes for SSG Permanent TCP Redirection
Table 4 lists the vendor-specific attributes that can be configured in the RADIUS service profile to
perform SSG permanent TCP redirection. The service profile is downloaded from the authentication,
authorization, and accounting (AAA) server as part of user authentication.
Table 4 Vendor-Specific RADIUS Attributes for the SSG Permanent TCP Redirection Feature
Subattribute Subattribute
Attribute ID Vendor ID ID Type Subattribute Data
26 9 251 Service-Info KWserver-group-name—When a user logs in to the service, SSG
redirects the user’s HTTP traffic to a server in the specified server
group. All the service features (such as quality of service (QoS)
and prepaid billing) are applied to the HTTP traffic.
Example: ssg-service-info = KWhttp-proxy-isp_a
26 9 251 Service-Info KW0—When a user logs in to the service, SSG allows all HTTP
traffic to go to the service, without redirection, as if there are no
HTTP-proxy server settings in the user’s browser.
Note The service network entries must include the actual

HTTP proxy address.
This subattribute takes precedence over the 26,9,251

KWserver-group-name attribute.
Example: ssg-service-info = KW0

78-17497-01 219
Per-Session Firewall Overview

SSG uses Cisco IOS software access control lists (ACLs) to prevent users, services, and pass-through
traffic from accessing specific IP addresses and ports. This process is commonly referred to as a
per-session firewall.
Note Certain restrictions apply when using per-session firewalls for SSG. see Restrictions for Per-Session
Firewall, page 221, before configuring Per-Session firewalls.
This section describes the following SSG per-session firewall concepts:

• Access List Attributes for User and Service Profiles, page 220
• Downstream Access Control List Attribute—outacl, page 220
• Upstream Access Control List Attribute—inacl, page 221
• Restrictions for Per-Session Firewall, page 221
For detailed information about configuring per-session firewalls for SSG, see Configuring a Per-Session
Firewall, page 248.
Access List Attributes for User and Service Profiles

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, the attribute applies globally to all traffic for the user.
Transparent pass-through 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.
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, ACLs, and timeouts. User profiles are
configured on the RADIUS server or directly on the router. The RADIUS server or SESM downloads
the user profiles to the router.
Downstream Access Control List Attribute—outacl

The following Cisco-AV pair attribute specifies either a Cisco IOS software 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}"
Syntax Description
number Access list identifier.

standard-access-control-list Standard access control list.
extended-access-control-list Extended access control list.

220 78-17497-01
Example
Cisco-AVpair = "ip:outacl#101=deny tcp 10.168.1.0 0.0.0.255 any eq 21"
Note Multiple instances of the Downstream Access Control List attribute can occur within a single
profile. Use one attribute for each ACL statement. You can use multiple attributes for the
same ACL. Multiple attributes are downloaded according to the number specified and are
executed in that order.
Upstream Access Control List Attribute—inacl

The following Cisco-AV pair attribute specifies either a Cisco IOS software 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 |
Syntax Description

Example
Cisco-AVpair = "ip:inacl#101=deny tcp 10.168.1.0 0.0.0.255 any eq 21"
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. You can use multiple
attributes for the same ACL. Multiple attributes are downloaded according to the number
specified and are executed in that order.
Restrictions for Per-Session Firewall

Per-Session Firewall 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 software ACLs;
however, the log option is not accepted.
• SSG supports mini-ACLs with eight or less access control entries (ACEs), which 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.

78-17497-01 221
• SSG ACLs take precedence over Cisco IOS software ACLs. If you configure a Cisco IOS software
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.
Default DNS Redirection Overview

SSG default DNS redirection allows a default Domain Name System (DNS) domain to be configured in
a service profile. When a default DNS domain is configured in a service profile, all DNS queries that do
not match a domain name are redirected to the DNS server for that service.
This section describes the following DNS redirection concepts:
• DNS Redirection for Unauthenticated Users, page 222
• SSG Domain Name Vendor-Specific Attribute, page 223
• Restrictions for Dynamic DNS Assignment, page 223
For detailed information about configuring default DNS redirection, see Configuring Default DNS
Redirection, page 248.
DNS Redirection for Unauthenticated Users

The default domain can be configured to apply to DNS queries from unauthenticated users only. This
type of configuration enables SSG to redirect all DNS queries for unauthenticated users to the
Cisco Subscriber Edge Services Manager (SESM) DNS server, which can spoof the responses if
required.
A domain name within the question section of the DNS packet is compared in sequence in the upstream
path.
The sequence is as follows:
1. Domain names are configured in the logged-in services. If a match is found, the request is redirected
to the DNS server for the matched service.
2. Domain names are configured in the open garden service. If a match is found, the request is
redirected to the DNS server for the open garden service.
3. Default DNS domains are defined as an asterisk [*] in logged-in and in open garden services.
4. If 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, which is defined as
access to a service containing a Service Route attribute of 0.0.0.0/0.
5. If there is an open garden Internet service, the request is redirected to this service.
6. If a match is not found until now, the request is forwarded to the DNS server defined in the client’s
TCP/IP stack.
Default DNS redirection is useful in a public wireless LAN (PWLAN) environment in which a user's
browser may be configured with a home page that is part of a corporate internal network. Since the home
page domain will never be resolved by a DNS server in the Internet, the TCP session from the user will
never be initiated. Default DNS redirection allows SSG to redirect all DNS queries to a DNS server that
can resolve all queries—for example, the DNS server on the Cisco Subscriber Edge Services Manager
(SESM), which can spoof all unresolved DNS queries.

222 78-17497-01
SSG Domain Name Vendor-Specific Attribute

Table 5 describes the Domain Name vendor-specific attribute (VSA) used by SSG. The Domain Name
VSA specifies domain names that get DNS resolution from the DNS servers specified in the DNS server
address.
Table 5 SSG Vendor-Specific Attribute for Domain Name
Subattribute Subattribute
Attribute ID Vendor ID ID and Type Name Subattribute Data
26 9 251 Domain Name O{name1[;name2]...[;nameX] | *[;unauthenticated]}
Service-Info
name1—Domain name that gets DNS resolution from this server.
name2...x—Additional domain names that get DNS resolution
from this server.
*—Default domain for all DNS queries. Note that this cannot be
part of a list of domain names.
*O;unauthenticated—Default domain that applies to DNS queries
for unauthenticated users only. This is useful in a wireless LAN
environment in which SSG redirects all DNS queries for
unauthenticated users to the SESM DNS server, which can spoof
the responses if required.
Example:
ssg-service-info = "Ocisco.com;cisco-sales.com"
Example:
ssg-service-info = "O*;unauthenticated"
Restrictions for Dynamic DNS Assignment

When the DNS redirection server is statically configured in the service profile with SSG attributes, the
following restrictions apply:
• For mobile deployments, the mobile operator must configure ISP DNS addresses for users to
connect to.
• For any given service, after the attributes are downloaded, they are applied to all connections for that
service. This is not a restriction for proxy or dial-in tunnel services (where all users are usually
assigned the same DNS addresses). However, for L2TP dial-out tunnel cases, the same tunnel can
be used to connect to different ISPs, and thus different DNS addresses may be required.
These DNS redirections can now be dynamically assigned on a per-connection basis for proxy and tunnel
services. This is achieved by negotiation of the DNS addresses during authentication to the proxy or
tunnel service.
For all service connections, SSG is capable of learning the DNS addresses on a per-connection basis.
Any DNS addresses discovered in this way override DNS addresses that are statically configured in the
service profile. The mechanisms employed for discovering these DNS addresses are described in
Cisco-AVpair Attributes, page 224.

78-17497-01 223
How to Configure SSG Subscriber Experience Features
Cisco-AVpair Attributes
The Cisco-AVpair attributes are used in user and service profiles to configure ACLs and L2TP.
Table 6 lists the Cisco-AVpair attributes.
Table 6 Cisco-AVPair Attributes
Downstream Specifies either a Cisco IOS software standard ACL or an extended ACL to be
Access Control List applied to downstream traffic going to the user.
(outacl)
L2TP Tunnel Specifies the secret (the password) used for L2TP tunnel authentication.
Password
Upstream Access Specifies either a Cisco IOS software standard ACL or an extended ACL to be
Control List (inacl) applied to upstream traffic coming from the user.
VPDN IP Address Specifies the IP addresses of the home gateways (LNSes) to receive the L2TP
connections.
VPDN Tunnel ID Specifies the name of the tunnel that must match the tunnel ID specified in the
LNS VPDN group.

• Configuring SSG Hierarchical Policing, page 224
• Configuring SSG TCP Redirection Features, page 229
• Configuring a Per-Session Firewall, page 248
• Configuring Default DNS Redirection, page 248
For conceptual information about SSG subscriber experience features, see Information About SSG
Subscriber Experience Features, page 208.
Configuring SSG Hierarchical Policing

Perform the following tasks to configure SSG hierarchical policing:
• Configuring a RADIUS User Profile for Per-User Policing, page 224
• Configuring SSG Hierarchical Policing in a RADIUS Service Profile, page 225
• Enabling SSG Hierarchical Policing on the Router, page 226
• Troubleshooting SSG Hierarchical Policing, page 227
For conceptual information about SSG hierarchical policing, see SSG Hierarchical Policing Overview,
page 209.
Configuring a RADIUS User Profile for Per-User Policing

To accommodate per-user policing, modify the subscriber user profile to define the average bandwidth
that the user is entitled to obtain, and the normal and excess-burst tolerance that the user can have.

224 78-17497-01
To configure a RADIUS user profile for per-user policing, add the following attribute to the user profile:
Account-Info = “QU;upstream-bandwidth;upstream-normal-burst;
[upstream-excess-burst];D;downstream-bandwidth;
downstream-normal-burst;[downstream-excess-burst]”
Example
Account-Info = “QU;80000;40000;50000;D;80000;40000;50000”
Note For details on how to modify a RADIUS user profile, see your RADIUS server documentation.
Configuring SSG Hierarchical Policing in a RADIUS Service Profile

For per-session policing, the RADIUS service profile (which can be configured in a remote AAA server
or locally, on the router) has to be modified to accommodate SSG Hierarchical Policing. The service
profile defines the average rate a service has to achieve and the normal and excess-burst size the service
can tolerate to provide corresponding quality of service.
Modifying the RADIUS Service Profile on the AAA Server

To configure a service profile for per-session policing on the AAA server, add the following attribute to
the service profile:
Service-Info = “QU;upstream-token-rate;upstream-normal-burst;
[upstream-excess-burst];D;downstream-token-rate;
downstream-normal-burst;[downstream-excess-burst]”
Example
Service-Info = “QU;40000;20000;25000;D;40000;20000;25000”
Note For details on how to modify a service profile for per-session policing on the AAA server, see your AAA
server documentation.
Modifying the RADIUS Service Profile Locally on the Router

To configure a service profile with all of the policing parameters locally on the router, enter the following
commands:
SUMMARY STEPS
1. enable
3. local-profile profile-name
4. attribute radius-attribute-id vendor-id cisco-vsa-type
“QU;upstream-token-rate;upstream-normal-burst;[upstream-excess-burst];D;downstream-token-rate;
downstream-normal-burst;downstream-excess-burst”

78-17497-01 225
DETAILED STEPS

Step 1 enable Enables priviledged EXEC mode.
Example:
Router> enable
Example:
Step 3 local-profile profile-name Enters profile configuration mode. Configures
a local RADIUS service profile.
Example:
Router(config)# local-profile profile-2065
Step 4 attribute radius-attribute-id vendor-id cisco-vsa-type Configures the policing attributes in a local
“QU;upstream-token-rate;upstream-normal-burst; RADIUS service profile.
[upstream-excess-burst];D;downstream-token-rate;
downstream-normal-burst;downstream-excess-burst” The Q parameter (as shown in the command)
represents QoS. The variables are used to
configure upstream (U) and downstream (D)
Example:
policing. The upstream traffic is the traffic
Router(config-prof)# attribute 26 9 251“QU;80000;40000;
50000;D;downstream-token-rate;40000;50000” that travels from the subscriber to the
network, while the downstream traffic is the
traffic that travels from the network to the
subscriber.
SSG Hierarchical Policing can be configured
in either direction or in both directions
simultaneously.
Enabling SSG Hierarchical Policing on the Router

After you configure the SSG hierarchical policing parameters in the user or service profile, enter the ssg
qos police command on the router to enable per-user or per-session policing.
Note To disable SSG Hierarchical Policing on a router, use the no ssg qos police user and the no ssg qos
police session commands.
SUMMARY STEPS
1. enable
3. ssg qos police user

226 78-17497-01
4. ssg qos police session
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ssg qos police user Enables SSG per-user policing on the router.
Example:
Router(config)# ssg qos police user
Step 4 ssg qos police session Enables SSG per-session policing.
Example:
Router(config)# ssg qos police session
Troubleshooting SSG Hierarchical Policing

Use the following commands to troubleshoot the SSG Hierarchical Policing feature:
SUMMARY STEPS
1. show ssg host

2. show ssg connection
3. debug ssg data

78-17497-01 227
DETAILED STEPS

Step 1 show ssg host Displays information about an SSG host, including whether
policing is enabled or disabled and the policing configurations of a
particular host.
Example:
Router# show ssg host Ust the show ssg host command to verify per-user policing.
Step 2 show ssg connection Displays information about a particular SSG connection, including
the policing parameters.
Example:
Router# show ssg connection
Step 3 debug ssg data Displays SSG QoS information.
Example:
Router# debug ssg data

228 78-17497-01
Configuring SSG TCP Redirection Features

This section describes how to configure SSG TCP Redirection features that allow SSG to redirect TCP
packets, based on the destination port number.
For conceptual information about SSG TCP Redirection features, see SSG TCP Redirect Features
Overview, page 213.
Note SSG must be enabled by configuring the ssg enable command before these configurations can be
completed. See the Service Selection Gateway feature module for Cisco IOS Release 12.2(4)B for
detailed information about configuring SSG.
Perform the following tasks to configure TCP redirection features:

• Enabling SSG TCP Redirect for Services (Required), page 229
• Defining a Captive Portal Group, page 231
• Configuring Initial and Periodic Captivation, page 232
• Associating an Access Control List with a Redirection Group, page 234
• Verifying SSG TCP Redirect Access Control Lists, page 236
• Configuring TCP Redirection of Unauthenticated Subscribers, page 237
• Configuring TCP Ports for Redirection, page 238
• Configuring Unauthorized Service Redirection, page 239
• Configuring SMTP Redirection, page 241
• Configuring the RADIUS Attributes for SSG TCP Redirection, page 242
• Configuring Permanent TCP Redirection for HTTP Proxy Support, page 242
• Verifying SSG TCP Redirect for Services, page 244
• Troubleshooting SSG TCP Redirection, page 246
For conceptual information about SSG TCP Redirection features, see SSG TCP Redirect Features
Overview, page 213.
Enabling SSG TCP Redirect for Services (Required)

To enable the SSG TCP Redirect for Services feature, use the following commands beginning in global
configuration mode:
Note You must enable Cisco Express Forwarding (CEF) on the router before SSG functionality can be
enabled.

78-17497-01 229
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.
Note CEF must be enabled for SSG to work.
Restrictions for SSG TCP Redirect for Services
SSG TCP Redirect for Services feature has the following restrictions:
• SSG TCP Redirect for Services requires Cisco SESM Release 3.1(1) to handle unauthenticated
redirections. For other types of redirection, SESM Release 3.1.1. is required.
• The server defined in a server group must be globally routable.
• Traffic from hosts with overlapping IP addresses can be redirected only to SESMs with port bundle
host keys.
• When overlapping IP address support is enabled (the host key feature is enabled), a host can reach
the SSG only by a particular interface on the SSG. All packets between the host and the SSG use
this interface and must not be changed.
• Once the servers in a group have been configured, the routes to those servers do not change. SSG
TCP Redirect for Services does not work if packets from servers that require redirection are received
on a non-SSG interface.
• SSG TCP Redirect for Services does not support TCP sessions that can remain idle for more than
one minute.
SUMMARY STEPS
1. enable
3. ip cef
4. ssg enable
5. ssg tcp-redirect
DETAILED STEPS

Example:
Router> enable
Example:

230 78-17497-01

Step 3 ip cef Enables global IP CEF on the router.
Example:
Router(config)# ip cef
Step 4 ssg enable Enables SSG functionality.
Example:
Router(config)# ssg enable
Example:
Defining a Captive Portal Group

To define a group of one or more servers that make up the captive portal group, use the following
commands beginning in global configuration mode:
SUMMARY STEPS
1. enable
3. ssg tcp-redirect
6. (Optional) Repeat steps 3. to 5. for each captive portal group.
DETAILED STEPS

Example:
Router> enable
Example:

78-17497-01 231

Example:
Step 4 server-group group-name Defines the group of one or more servers that
make up a named captive portal group and
enters SSG-redirect-group configuration mode.
Example:
Router(config-ssg-redirect)# server-group capt_portgroup group-name—Name of the captive portal group.
• ip-address—IP address of the server to add
Example: to the captive portal group.
Router(config-ssg-redirect-group)# server 10.2.2.2 24
• port—TCP port of the server to add to the
captive portal group.
Step 6 (Optional) Repeat steps 3. to 5. for each captive portal group. Defines additional groups of servers to add to
the captive portal group.
Configuring Initial and Periodic Captivation

To select the default captive portal group for initial captivation of users when they log in, use the
following command beginning in global configuration mode:
SUMMARY STEPS
1. enable
3. ssg tcp-redirect
4. redirect captivate initial default group group-name duration seconds
5. redirect captivate advertising default group group-name duration seconds frequency frequency
DETAILED STEPS

Example:
Router> enable
Example:

232 78-17497-01

Example:
Step 4 redirect captivate initial default group group-name Selects the default captive portal group for
duration seconds initial captivation of users upon initialization.
• group-name—Name of the captive portal
Example: group.
Router(config-ssg-redirect)# redirect captivate initial
default group group-name duration seconds • seconds—The duration in seconds of the
initial captivation. The valid range is 1 to
65,536 seconds.
Step 5 redirect captivate advertising default group group-name Selects the default captive portal group for
duration seconds frequency frequency captivation of advertisements for users.
• group-name—Name of the captive portal
Example: group.
Router(config-ssg-redirect)# redirect captivate
advertising default group group-name duration seconds • seconds—The duration in seconds of the
frequency frequency advertising captivation. The valid range is 1
to 65,536 seconds.
• frequency—The frequency in seconds at
which TCP packets are redirected to the
captive portal group. The valid range is 1 to
65536 seconds.

78-17497-01 233
Associating an Access Control List with a Redirection Group

To associate an access control list with an SSG TCP redirection group, follow these steps:
Prerequisites
This task assumes that you know how to configure an IP access control list.
SUMMARY STEPS
1. enable
3. ssg tcp-redirect
6. exit
7. redirect port port-number to group-name
or
redirect port-list port-listname to group-name
8. redirect access-list {number | name} to group-name
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ssg tcp-redirect Enables SSG TCP redirect functionality and enters
SSG-redirect configuration mode.
Example:
Step 4 server-group group-name Defines the group of one or more servers that make up a
named captive portal group and enters SSG-redirect-group
configuration mode.
Example:
Router(config-ssg-redirect)# server-group SESM1 • group-name—Name of the captive portal group.

234 78-17497-01

Router(config-ssg-redirect-group)# server
10.10.10.10 8080
• port—TCP port of the server to add to the captive portal
group.
Step 6 exit Exits SSG-redirect-group configuration mode.
Example:
Router(config-ssg-redirect-group)# exit
Step 7 redirect port port-number to group-name (Optional) Configures a TCP port or named TCP port list
for SSG TCP redirection.
or
• port—Specifies a TCP port to mark for SSG TCP
redirection.
• port-list—Specifies the named TCP port list to mark
for SSG TCP redirection.
Example:
Router(config-ssg-redirect)# redirect port 80 • port-number—Specifies the incoming destination port
to SESM1 number of the TCP port to mark for SSG TCP
redirection.
or
• group-name—Defines the name of the captive portal
Router(config-ssg-redirect)# redirect port-list
portlist1 to SESM1
group to redirect packets that are marked for a
destination port or named TCP port list.
• port-listname—Specifies the name of the named TCP
port list.
Step 8 redirect access-list {number | name}[to Configures an access control list for SSG TCP redirection.
group-name]
• If a server group is not specified, the access list is used
for redirection to any server group that does not have an
Example: access list associated with it.
Router(config-ssg-redirect)# redirect
access-list 80 to SESM1

78-17497-01 235
Verifying SSG TCP Redirect Access Control Lists

Perform this task to verify that an access control list is associated with an SSG TCP redirection group.
SUMMARY STEPS
1. show ssg tcp-redirect group

2. show ssg tcp-redirect group group-name
DETAILED STEPS

Step 1 show ssg tcp-redirect group Displays a list of all defined portal groups.
Verifies that the default access list for
Example: redirection is listed in the output.
Router# show ssg tcp-redirect group
Current TCP redirect groups:

SESM1
SESM2
Default access-list: 101
Default unauthenticated user redirect group: None Set
Default service redirect group: None Set
Prepaid user default redirect group: None Set
SMTP forwarding group: None Set
Default initial captivation group: None Set
Default advertising captivation group: None Set
Step 2 show ssg tcp-redirect group group-name Displays a list of all defined portal groups for a
server group with an access control list.
Example: Verifies that the redirected access control list is
Router# show ssg tcp-redirect group SESM1 listed in the server group configuration in the
output.
TCP redirect group SESM1:
Showing all TCP servers (Address, Port):
10.1.1.1, 100,
No redirectable destination networks defined.
No redirectable TCP ports defined.
Access list to match: 105

236 78-17497-01
Configuring TCP Redirection of Unauthenticated Subscribers

To select a captive portal group for redirection of traffic from unauthorized users, use the following
commands beginning in global configuration mode:
SUMMARY STEPS
1. enable
3. ssg tcp-redirect
4. redirect unauthenticated-user to group-name
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Step 4 redirect unauthenticated-user to group-name Selects a captive portal group for redirection of
traffic from unauthenticated users.
Example: • group-name—Name of the captive portal
Router(config-ssg-redirect)# redirect group.
unauthenticated-user to mygroupname

78-17497-01 237
Configuring TCP Ports for Redirection

To define a port list, add TCP ports to a port list, and set a port or list of ports to be redirected by the
captive portal group, use the following commands beginning in global configuration mode:
SUMMARY STEPS
1. enable
3. ssg tcp-redirect
4. port-list port-listname
5. port port-number
6. exit
7. redirect port port-number to group-name
or
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Step 4 port-list port-listname Defines the port list and enters SSG-redirect-port
configuration mode.
Example: • port-listname—Defines the name of the port list.
Router(config-ssg-redirect)# port-list myportlist
Step 5 port port-number Adds a port to a port list.
• port-number—Incoming destination port
Example: number. The valid range of port numbers is 1 to
Router(config-ssg-redirect-port)# port 65534 65535

238 78-17497-01

Step 6 exit Exits SSG-redirect-port configuration mode.
Example:
Router(config-ssg-redirect-port)# exit
Step 7 redirect port port-number to group-name Configures a TCP port or named TCP port list for
SSG TCP redirection.
or
• port—Specifies a TCP port to mark for SSG
TCP redirection.
• port-list—Specifies the named TCP port list to
Example: mark for SSG TCP redirection.
Router(config-ssg-redirect)# redirect port 65534 to
myportgroup • port-number—Specifies the incoming
destination port number of the TCP port to mark
or for SSG TCP redirection.
• group-name—Defines the name of the captive
Router(config-ssg-redirect)# redirect port-list
myportlist to myportgroup
portal group to redirect packets that are marked
for a destination port or named TCP port list.
• port-listname—Specifies the name of the named
TCP port list.
Configuring Unauthorized Service Redirection

To configure a destination network for unauthorized service redirection, use the following commands
beginning in global configuration mode:
SUMMARY STEPS
1. enable
3. ssg tcp-redirect
4. network-list network-listname
5. network ip-address
6. exit
7. redirect unauthorized-service [destination network-list network-listname] to group-name
DETAILED STEPS

Example:
Router> enable

78-17497-01 239

Example:
Example:
Step 4 network-list network-listname Defines the network list and enters
SSG-redirect-network configuration mode.
Example: • network-listname—Defines the name of the
Router(config-ssg-redirect)# network-list network list.
mynetworklist
Step 5 network ip-address Adds the specified IP address to the named network
list.
Example: • ip-address—The IP address to add to a named
Router(config-ssg-redirect-network)# network network list.
ip-address 10.2.2.2
Step 6 exit Exits SSG-redirect-network configuration mode.
Example:
Router(config-ssg-redirect-network)# exit
Step 7 redirect unauthorized-service [destination Creates a list of destination IP networks that can be
network-list network-listname] to group-name redirected by the named captive portal group.
• (Optional) destination network-list—Checks
Example: to determine if incoming packets from
Router(config-ssg-redirect)# redirect authenticated hosts require redirection to
unauthorized-service destination network-list
authorized networks.
mynetworklist to myportgroup
• (Optional) network-listname—Name of the list
of destination IP networks.
• group-name—Name of the captive portal group.
Note If you do not specify a destination IP
network by configuring the optional
destination network-list keywords, the
captive portal group specified in the
group-name argument is used as the default
group for unauthorized service redirection
when the IP address of the unauthorized
packet does not fall into any network list
associated with the captive portal group.

240 78-17497-01
Configuring SMTP Redirection

To select a captive portal group for redirection of Simple Mail Transfer Protocol (SMTP) traffic, use the
following commands beginning in global configuration mode:
SUMMARY STEPS
1. enable
3. ssg tcp-redirect
4. redirect smtp group group-name [all | user]
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Step 4 redirect smtp group group-name [all | user] Selects a captive portal group for redirection of
SMTP traffic.
Example: • group-name—Name of the captive portal group.
Router(config-ssg-redirect)# redirect smtp group
myportgroup all
• (Optional) all—All SMTP packets are
forwarded.
• (Optional) user—Forwards SMTP packets from
users who have SMTP forwarding permissions.
Note If you do not configure the optional all or
user keywords, the default is all.

78-17497-01 241
Configuring the RADIUS Attributes for SSG TCP Redirection

To configure the RADIUS attributes for SSG TCP Redirection, use the vendor-specific RADIUS
attributes listed in this section in the user profiles on the AAA server. The user profile is downloaded
from the AAA server as part of user authentication.
Table 7 lists vendor-specific RADIUS attributes required in the user profile to perform SSG TCP
redirection.
Table 7 Vendor-Specific RADIUS Attributes for the SSG TCP Redirect for Services Feature
Attribute Account-Info
ID VendorID SubAttrID SubAttr Name SubAttrDataType Feature Code
26 9 250 Account-Info String R
Allowable additional features:

• “S”—User has SMTP forwarding capability.
• “Igroup;duration[;service]”—User has initial captivation capability. This attribute also indicates the
duration of the captivation in seconds. If you specify the optional service field, initial captivation
starts only when the user activates the named service.
• “Agroup;duration;frequency[;service]—User has advertisement captivation capability. Specifies the
captive portal group to use, the duration and approximate frequency of the captivation in seconds.
If you add the optional service field, advertisement captivation starts only when the user activates
the named service.
Configuring Permanent TCP Redirection for HTTP Proxy Support

To configure permanent TCP redirection for authenticated and unauthenticated users with HTTP proxy
server configurations, perform this task.
Prerequisites for Configuring SSG Permanent TCP Redirection
Before configuring permanent TCP redirection, perform the following tasks:

• Configure captive portal server groups for authenticated and unauthenticated HTTP-proxy users, see
“Defining a Captive Portal Group” section on page 231.
• Configure SESM to support SSG redirection.
Note To enable HTTP proxy users to reach SESM, provide a globally routable IP address to
SESM.
SUMMARY STEPS
1. enable
3. ssg tcp-redirect
4. redirect permanent http authenticated to server-group
5. redirect permanent http unauthenticated to server-group

242 78-17497-01
6. end
7. Configure the RADIUS service profile to support permanent TCP redirection, see “RADIUS
Attributes for SSG Permanent TCP Redirection” section on page 219.
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ssg tcp-redirect Enables SSG TCP redirect and enters SSG-redirect
configuration mode.
Example:
Step 4 redirect permanent http authenticated to Specifies a server group for permanent TCP redirections for
server-group authenticated users with HTTP proxy server configurations.
• server-group—Name of the local HTTP proxy server
Example: group for authenticated users
Router(config-ssg-redirect)# redirect permanent
http authenticated to auth_servergroup
Step 5 redirect permanent http unauthenticated to Specifies a server group for permanent TCP redirections for
server-group unauthenticated users with HTTP proxy server
configurations.
Example: • server-group—Name of the local HTTP proxy server
Router(config-ssg-redirect)# redirect permanent group for unauthenticated users
http unauthenticated to unauth_servergroup
Step 6 end (Optional) Returns to global configuration mode.
Example:
Router(config-ssg-redirect)# end
Step 7 Configure the RADIUS service profile to support The RADIUS service profile is downloaded from the AAA
permanent TCP redirection. server as part of service authorization. Configure one of the
following attributes in the service profile to support
permanent TCP redirection:
• ssg-service-info = KWserver-group-name
• ssg-service-info = KW0
See the “RADIUS Attributes for SSG Permanent TCP
Redirection” section on page 219 for more information
about the RADIUS attributes for permanent TCP
redirection.

78-17497-01 243
Verifying SSG TCP Redirect for Services

Use the following show commands to verify the SSG TCP Redirect for Services configuration.
SUMMARY STEPS
3. show ssg tcp-redirect mappings [ip-address [interface]]
4. show ssg host ip-address
DETAILED STEPS

Step 1 show running-config Displays the current SSG TCP Redirect for
Services configuration.
Example:
Router# show running-config
ssg tcp-redirect
network-list RedirectNw
network 10.16.10.0 255.255.255.0
network 10.20.0.0 255.255.0.0
!
port-list WebPorts
port 80
.
.
.
.
Step 2 show ssg tcp-redirect group [group-name] Displays a list all configured captive portal
groups, and indicates which group is used for
redirected packets from unauthorized users.
Example:
This show command also displays which captive
Router# show ssg tcp-redirect group portal groups are the default groups for
captivation and unauthorized service
RedirectServer redirection.
CaptivateServer • group-name—(optional) Name of the
SMTPServer
SSD
captive portal group.
If you do not enter the optional group-name
Unauthenticated user redirect group:RedirectServer
argument, the show ssg tcp-redirect group
Default service redirect group:SSD
SMTP forwarding group:SMTPServer, for all users command displays a list of all defined portal
Default initial captivation group:CaptivateServer, groups. If the group-name argument is included,
for 10 seconds the command displays information about the
Default advertising captivation group:CaptivateServer, specified portal group.
for 30 seconds approximately every 3600 seconds

244 78-17497-01

Step 3 show tcp-redirect mappings [ip-address [interface]] Displays any direct mappings, and TCP redirect
statements in the output.
Example: • ip-address—(optional) The host IP address.
Router# show tcp-redirect mappings

If you do not enter the optional ip-address
argument, the show tcp-redirect mappings
Authenticated hosts: command displays a list of IP addresses for
TCP remapping Host:10.16.10.0 to servers (IP:Port) all hosts with stored mappings. If the
10.2.36.253:8080 ip-address argument is included, all
10.64.131.20:25
### Total authenticated hosts being redirected = 1
mappings for the host with the specified IP
address are displayed.
Unauthenticated hosts:
• interface—(optional) The interface on
TCP remapping Host:10.0.0.2 to server:10.2.36.253 on which the host is connected to SSG.
port:80 80 Use the optional interface argument in port
Router# show tcp-redirect mappings 10.16.0.0
bundle host key mode to specify the
interface on which the host is connected to
TCP remapping Host:10.16.10.0 the SSG. Use the output displayed by this
TCP remapping to server:10.2.36.253 on port:8080 command to distinguish hosts with
Connection Mappings (src port <-> dest IP,dest overlapping IP addresses.
port,timestamp, flags):
11092 <-> 10.0.0.1,80,730967636,0x1
TCP remapping to server:10.64.131.20 on port:25
Connection Mappings (src port <-> dest IP,dest
port,timestamp,flags):
11093 <-> 10.0.0.1,25,730967652,0x0

78-17497-01 245

Step 4 show ssg host ip-address Displays information about a subscriber that is
specified by the entered IP address.
Example:
--------- HostObject Content --------------

Activated:TRUE
Interface:
User Name:dev-user1
Host IP:10.16.0.0
Msg IP:0.0.0.0 (0)
Host DNS IP:0.0.0.0
Maximum Session Timeout:0 seconds
Host Idle Timeout:0 seconds
Class Attr:NONE
User logged on since:*07:20:57.000 UTC Mon Dec 3 2001
User last activity at:*07:20:59.000 UTC Mon Dec 3 2001
SMTP Forwarding:NO
Initial TCP captivate:YES
(default) to group CaptivateServer for 10 seconds
TCP Advertisement captivate:YES
(default) to group CaptivateServer for 10 seconds,
approximately every 20 seconds
Default Service:NONE
DNS Default Service:NONE
Active Services:inet1;
AutoService:NONE
Subscribed Services:proxynat1; tunnel1; proxy1;
passthru1;
Subscribed Service Groups:NONE
Troubleshooting SSG TCP Redirection

Use the following commands to troubleshoot the SSG TCP Redirect for Services feature:
SUMMARY STEPS
1. show ssg host [ip-address]

3. show tcp-redirect mappings [ip-address] [interface]
4. debug ssg tcp-redirect {packet | error | event}
DETAILED STEPS

Step 1 show ssg host [ip-address] Displays information about a subscriber and current
connections of the subscriber.
Example:

246 78-17497-01

Step 2 show ssg tcp-redirect group [group-name] Lists all configured captive portal groups and
indicates which group receives redirected packets
from unauthorized users. If the group-name is
Example:
Router# show ssg tcp-redirect group mygroup
specified, this command displays detailed
information about that captive portal group.
Step 3 show tcp-redirect mappings [ip-address] [interface] Displays the redirect mappings currently stored in
SSG. If the host ip-address is provided, this
command displays detailed redirect mapping
Example:
Router# show tcp-redirect mappings 10.168.0.1
information for the specified host. The TCP redirect
myinterface mappings are removed automatically after the TCP
session terminates or is idle for more than 60
seconds.
Step 4 debug ssg tcp-redirect {packet | error | event} Use this command to turn on debug information for
the SSG TCP Redirect for Services feature.
Example: • packet—Displays redirection information and
Router# debug ssg tcp-redirect packet any changes made to a packet when it is due for
redirection.
• error—Displays any SSG TCP redirect errors.
• event—Displays any major SSG TCP redirect
events or state changes.
Note This command replaces the debug ssg
http-redirect command.

78-17497-01 247
Configuring a Per-Session Firewall

SSG uses Cisco IOS software access control lists (ACLs) to prevent users, services, and pass-through
traffic from accessing specific IP addresses and ports. This is known as a per-session firewall.
Note Certain restrictions apply when configuring per-session firewalls. Before configuring a per-session
firewall, see Per-Session Firewall Overview, page 220.
To configure SSG ACLs, configure the following Cisco-AV pair attributes in your user or service profile
on the AAA server:
• Downstream Access Control List (outacl)
• Upstream Access Control List (inacl)

Note The method used to configure these attributes depends upon the AAA server. see your AAA server
documentation for details.
Example Configuration for Per-Session Firewall

The following is an example of a downstream ACL (outacl):
The following is an example of an upstream ACL (inacl):

Configuring Default DNS Redirection
Note Certain restrictions apply when configuring default DNS redirection. Before configuring default DNS
redirection, see Default DNS Redirection Overview, page 222.
Perform the following tasks to configure default DNS redirection:

• Configuring DNS Redirection in a Local Service Profile using the Cisco IOS CLI, page 249
• Configuring Dynamic DNS Assignment on the AAA Server, page 250
• Configuring DNS Fault tolerance, page 250
For conceptual information about default DNS redirection,see Default DNS Redirection Overview,
page 222.

248 78-17497-01
Configuring DNS Redirection in a Local Service Profile using the Cisco IOS CLI
This task configures SSG default DNS redirection in a local service profile.
You can also configure SSG default DNS redirection by adding the VSA for default DNS redirection to
the service profile on the RADIUS server. See the SSG Domain Name Vendor-Specific Attribute,
page 223 for information about the Domain Name VSA.
SUMMARY STEPS
1. enable
3. local-profile profile-name
4. attribute 26 9 251 "O*[;unauthenticated]"
5. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 local-profile profile-name Configures a local service profile and enters profile
configuration mode.
Example:
Router(config)# local-profile og-dns
Step 4 attribute 26 9 251 "O*[;unauthenticated]" Configures the attribute for default DNS redirection in a
local service profile.
Example:
Router(config-prof)# attribute 26 9 251 "O*"
Example:
Router(config-prof)# end
Step 6 show ssg service [service-name [begin (Optional) Displays the information for about a service. The
expression | exclude expression | include output for this command indicates if default DNS matching
expression]]
is enabled and whether it is valid for unauthenticated users
only.
Example:
Router# show ssg service og-dns

78-17497-01 249
Configuration Examples for Configuring SSG Subscriber Experience Features
Configuring Dynamic DNS Assignment on the AAA Server

This feature works automatically and is dependent on what SSG receives from a remote AAA server. No
configuration is required on the SSG itself. These attributes must be configured in the relevant "service
profile" on the AAA server.
For proxy services, the DNS address(es) are signaled in the Access-Accept from the proxy AAA server.
This can be via one of the following attributes:
• Cisco AV-pairs ("ip:dns-servers=10.44.216.10 171.69.11.48")
• Ascend Non-Standard attributes (attrs#135 and #136)
SSG recognizes DNS addresses that are communicated in either of these formats and associates them
with the relevant service and connection using the previously stated algorithm.
For details of the Cisco AV attributes see Restrictions for Dynamic DNS Assignment, page 223.
Configuring DNS Fault tolerance

You can also configure SSG default DNS tolerance by adding the VSA for default DNS redirection to
the service profile on the RADIUS server.
See the SSG Domain Name Vendor-Specific Attribute, page 223 for information about the Domain
Name VSA.
Configuration Examples for Configuring SSG Subscriber

Experience Features
• Enabling SSG TCP Redirect for Services: Example, page 251
• Defining a Captive Portal Group: Example, page 251
• Excluding Specific Traffic from Redirection: Example, page 251
• Redirecting Traffic from Unauthenticated Users: Example, page 251
• Configuring TCP Redirection of Unauthenticated Subscribers: Example, page 252
• TCP Ports for a Portal Group Configuration: Example, page 252
• Default Portal Group for Captivation: Example, page 252
• Destination Networks Configuration: Example, page 253
• Portal Group for SMTP Redirect Configuration: Example, page 253
• RADIUS Attributes for SSG TCP Redirect Configuration: Example, page 253
• SSG Default DNS Redirection Configuration: Example, page 254
• SSG Default DNS Redirection for Unauthenticated Users Configuration: Example, page 254

250 78-17497-01
Enabling SSG TCP Redirect for Services: Example

The following example shows how to enable the SSG TCP Redirect for Services feature:
ssg enable
ssg tcp-redirect
Defining a Captive Portal Group: Example

The following example shows how to configure a group of one or more servers that make up the captive
portal group. In the following example, the server with IP address 10.16.0.0 and port 8080, and the server
with IP address 10.32.10.0 and port 8081, are added to the captive portal group named “RedirectServer”:
ssg enable
ssg tcp-redirect
server-group RedirectServer
server 10.16.0.0 8080
server 10.32.10.0 8081
Excluding Specific Traffic from Redirection: Example

The following example shows how to redirect packets that are not destined to server 10.0.0.1 for initial
captivation:
ssg tcp-redirect
server-group InitialCapt
server 10.1.1.1 8090
!
redirect port 80 to InitialCapt
redirect access-list 101 to InitialCapt
!
redirect captivate initial default group InitialCapt duration 30
!
access-list 101 deny ip any host 10.0.0.1
access-list 101 permit ip any any
Redirecting Traffic from Unauthenticated Users: Example

The following example shows how to redirect unauthenticated host traffic from subnet 10.1.0.0/16 to
server group SESM1. Any other unauthenticated host traffic is redirected to SESM2.
ssg tcp-redirect
server-group SESM1
server 10.2.36.253 8080
!
redirect port 80 to SESM1
redirect access-list 50 to SESM1
redirect unauthenticated user to SESM1
!
server-group SESM2
server 10.2.36.254 8080
!
redirect port 80 to SESM2
redirect unauthenticated user to SESM2
redirect access-list 101
!
access-list 50 permit 10.1.0.0 0.0.255.255

78-17497-01 251
Configuring TCP Redirection of Unauthenticated Subscribers: Example

The following example shows how to select a captive portal group for redirection of traffic from
unauthorized users. In the following example, traffic from unauthorized users is redirected to the captive
portal group named “RedirectServer”:
ssg enable
ssg tcp-redirect
redirect unauthenticated-user to RedirectServer
TCP Ports for a Portal Group Configuration: Example

The following example shows how to define a port list named “WebPorts” and adds TCP ports 80 and
8080 to the port list. Port 8080 is configured to be redirected by the captive portal group named “Redirect
Server”:
ssg enable
ssg tcp-redirect
port-list WebPorts
port 80
port 8080
exit
redirect port 8080 to RedirectServer
The following example shows how to define a port list named “WebPorts” and adds TCP ports 80 and
8080 to the port list. The port list named “WebPorts” is configured to be redirected by the captive portal
group named “Redirect Server”:
ssg enable
ssg tcp-redirect
port-list WebPorts
port 80
port 8080
exit
redirect port-list WebPorts to RedirectServer
Default Portal Group for Captivation: Example

The following example shows how to select the default captive portal group for initial captivation of
users upon initialization (Account login) and the default captive portal group for advertising for a user.
In the following example, the captive portal group named “InitialCaptiveGroup” is selected as the default
destination for packets from a user for the first 10 seconds that the user is connected. The portal group
named “AdvertisingCaptiveGroup” is used to forward packets from a user for 20 seconds at an attempted
frequency of once every hour (3600 seconds):
ssg enable
ssg tcp-redirect
redirect captivate initial default group InitialCaptiveGroup duration 10
redirect captivate advertising default group AdvertisingCaptiveGroup duration 20
frequency 3600

252 78-17497-01
Destination Networks Configuration: Example

The following examples show how to configure a destination network for unauthorized service
redirection.
In the following example, a network list named “RedirectNw” is created and configured as the default
group for unauthorized service redirection. The networks at IP address 10.16.10.0 255.255.255.0 and
10.20.0.0 255.255.255.0 are added to the network list named “RedirectNw.”
ssg enable
ssg tcp-redirect
network 10.16.10.0 255.255.255.0
network 10.20.0.0 255.255.255.0
exit
redirect unauthorized-service destination network-list RedirectNw to RedirectServer
In the following example, because no destination network list is specified, the captive portal group
named “RedirectServer” is used as the default group for unauthorized service redirection.
ssg enable
ssg tcp-redirect
network 10.16.10.0 255.255.255.0
network 10.20.0.0 255.255.255.0
exit
redirect unauthorized-service to RedirectServer
Portal Group for SMTP Redirect Configuration: Example

The following examples show how to select a captive portal group for redirection of Simple Mail
Transfer Protocol (SMTP) traffic.
In the following example, the captive portal group named “SMTPServer” is used to forward SMTP
packets from any authorized user with the SMTP forwarding attribute.
ssg enable
ssg tcp-redirect
redirect smtp group SMTPServer user
In the following example the captive portal group named “SMTPServer” is used to forward any SMTP
packets from authorized users.
ssg enable
ssg tcp-redirect
redirect smtp group SMTPServer all
RADIUS Attributes for SSG TCP Redirect Configuration: Example
Note The RADIUS attributes shown in the following examples are configured in the user profiles on the AAA
server. The user profile is downloaded from the AAA server as part of user authentication.
The following example shows how to configure the user profile for initial captivation on account login
to one of the servers in the captive portal group named “CaptivateGrpA” for 300 seconds:

78-17497-01 253
ICaptivateGrpA;300
The following example shows how to configure the user profile for initial captivation upon service login
to the service “Games”:
ICaptivateGrpB;240;Games
The following example shows how to configure the user for captivation of advertisements while the host
is logged in to SSG:
ACaptivateGrpA;300;3600
The following example shows how to configure the user for captivation of advertisements to one of the
servers in the captive portal group called “CaptivateGrpB” for 240 seconds. The captivation of
advertisements begins when the user starts using the “Games” service and approximately every 1800
seconds thereafter:
ACaptivateGrpB;240;1800;Games
SSG Default DNS Redirection Configuration: Example

In the following example, all DNS packets are directed to the DNS server 10.6.6.2.
! Define the service profile locally
local-profile og-dns
attribute 26 9 251 "D10.6.6.2"
attribute 26 9 251 "R10.6.6.2;255.255.255.255"
attribute 26 9 251 "O*"
!
! Make the service an open garden
ssg open-garden og-dns
When a default DNS domain is configured, the output for the show ssg service command includes the
following:
Default domain matching is Enabled
SSG Default DNS Redirection for Unauthenticated Users Configuration:

Example
The following example shows how default DNS matching is applied only to unauthenticated users. If the
user is authenticated, the packet is processed normally.
! Define the service profile locally
local-profile og-dns-non-authen
attribute 26 9 251 "D10.6.6.2"
attribute 26 9 251 "R10.6.6.2;255.255.255.255"
attribute 26 9 251 "O*;unauthenticated"
!
! Make the service an open garden
ssg open-garden og-dns-non-authen
When a default DNS domain is configured for unauthenticated users only, the output for the show ssg
service command includes the following:
Default domain matching is Enabled - valid only for unauthenticated users

254 78-17497-01
Additional References Related to SSG Subscriber Experience Features
Additional References Related to SSG Subscriber Experience

Features
The following sections provide references related to SSG subscriber experience features.
Related Documents
SSG commands Cisco IOS Wide-Area Networking Command Reference,
Release 12.3 T
SESM Cisco Subscriber Edge Services Manager
Cisco Service Selection Dashboard
RADIUS commands Cisco IOS Security Command Reference, Release 12.3 T
RADIUS configuration tasks Cisco IOS Security Configuration Guide
Standards
Standards Title
No new or modified standards are supported by this —
feature. Support for existing standards has not been
modified by this feature.
MIBs
MIBs MIBs Link
No new or modified MIBs are supported by this To locate and download MIBs for selected platforms, Cisco IOS
feature. Support for existing MIBs has not been releases, and feature sets, use Cisco MIB Locator found at the
modified by this feature. following URL:
http://www.cisco.com/go/mibs
RFCs
RFCs Title
No new or modified RFCs are supported by this —
feature. Support for existing RFCs has not been
modified by this feature.

78-17497-01 255
Feature Information for Configuring SSG Subscriber Experience Features
Description Link
even more content.
Feature Information for Configuring SSG Subscriber Experience

Features
Table 8 lists the features in this module and provides links to specific configuration information.

256 78-17497-01
Table 8 Feature Information for Configuring SSG Subscriber Experience Features

Hierarchical Policing 12.2(4)B The SSG Hierarchical Policing feature ensures that a
12.2(13)T subscriber does not utilize additional bandwidth for overall
service or for a specific service that is outside the bounds of
the subscriber's contract with the service provider.
feature:
• “SSG Hierarchical Policing Overview” on page 209
• “Configuring SSG Hierarchical Policing” on page 224
• “Configuration Examples for Configuring SSG
Subscriber Experience Features” on page 250
SSG TCP Redirect 12.1(5)DC The SSG TCP Redirect feature redirects certain packets,
12.2(4)B which would otherwise be dropped, to captive portals that
12.2(8)T can handle the packets in a suitable manner.
12.3T
12.4
feature:
• “SSG TCP Redirect Features Overview” on page 213
• “Configuring SSG TCP Redirection Features” on
page 229
The following commands are introduced in this feature:
ssg tcp-redirect, redirect unauthenticated-user to.

78-17497-01 257
Table 8 Feature Information for Configuring SSG Subscriber Experience Features (continued)

Per-Session Firewall 12.0(3)DC The SSG Per Session Firewall feature enables you to
12.2(4)B configure Cisco IOS software access control lists (ACLs) to
12.2(8)T prevent users, services, and pass-through traffic from
accessing specific IP addresses and ports.
feature:
• “Per-Session Firewall Overview” on page 220
• “Configuring a Per-Session Firewall” on page 248
DNS Redirection 12.3(3)B The SSG DNS Redirection feature enables you to match a
12.3(7)T domain name server (DNS) request to the appropriate
domain name service, based on attributes of the user
requesting the service.
When the Cisco SSG receives a Domain Name System
(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. 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.
feature:
• “Default DNS Redirection Overview” on page 222
• “Configuring Default DNS Redirection” on page 248

258 78-17497-01
Configuring SSG to Log Off Subscribers
Service Selection Gateway (SSG) supports the following methods of subscriber logoff:
• Graceful logoff, in which the subscriber initiates the logoff procedure at the end of a session
• Disconnection through the Web Services Gateway (WSG)
• The SSG Autologoff feature, which automatically logs off SSG subscribers
• Session timeouts and idle timeouts
This document describes these logoff methods and explains how to configure SSG to implement them.
Module History
Finding Support Information for Platforms and Cisco IOS Software Images
and configuration, use the “Feature Information for Configuring SSG to Log Off Subscribers” section
on page 266.
Contents
• Prerequisites for Configuring SSG to Log Off Subscribers, page 259
• Information About Configuring SSG to Log Off Subscribers, page 260
• How to Configure SSG to Log Off Subscribers, page 262
• Configuration Examples for Configuring SSG to Log Off Subscribers, page 265
Prerequisites for Configuring SSG to Log Off Subscribers

Before you can perform the tasks in this module, SSG must be enabled.
The tasks in this document assume that you know how to configure Address Resolution Protocol (ARP)
and Internet Control Message Protocol (ICMP).

78-17497-01 259
Information About Configuring SSG to Log Off Subscribers

To configure SSG to log off subscribers, you should understand the following concepts:
• Graceful Logoff, page 260
• Disconnection Through the Web Services Gateways, page 260
• SSG Autologoff, page 260
• SSG Session Timeout and Idle Timeout, page 261
Graceful Logoff
Graceful logoff occurs when the subscriber decides to end a session and clicks the Log Off button. This
is the typical method of ending a session, and SSG supports it by default; you do not have to configure
SSG to support graceful logoff.
Disconnection Through the Web Services Gateways

A third-party management tool can use a Web Services Gateway (WSG), which is part of Cisco’s
Subscriber Edge Services Manager (SESM) system, to send logoff messages to SSG. For information
about configuring SESM to support disconnection through WSGs, refer to the Cisco Subscriber Edge
Services Manager documentation. You do not have to configure SSG to support disconnection through
WSGs.
SSG Autologoff
When SSG automatic logoff (autologoff) is configured, SSG checks the status of the connection with
each host at configured intervals. If SSG finds that a host is not reachable, SSG automatically initiates
the logoff of that host. SSG has two methods of checking the connectivity of hosts: ARP ping and ICMP
ping. The following sections provide more information about SSG Autologoff:
• SSG Autologoff Using ARP Ping, page 260
• SSG Autologoff Using ICMP Ping, page 261
• MAC Address Checking for Autologoff, page 261
• Benefits of SSG Autologoff, page 261
SSG Autologoff Using ARP Ping

ARP is an Internet protocol used to map IP addresses to MAC addresses. For directly connected devices,
the router broadcasts ARP requests that contain IP address information. When an IP address is
successfully associated with a MAC address, the router stores the information in the ARP cache.
When SSG autologoff is configured to use ARP ping, SSG periodically refreshes the ARP entry. If the
ARP entry is not found, SSG initiates autologoff for the host.
If any data traffic is flowing to or from the host during the interval, SSG does not ping the host.

260 78-17497-01
Note ARP ping should be used only in deployments where all hosts are directly connected to SSG through
a broadcast interface, such as an Ethernet interface, or a bridged interface, such as a routed bridge
encapsulation (RBE) or an integrated routing and bridging (IRB) interface.
ARP request packets are smaller than ICMP ping packets, so Cisco recommends that you configure SSG
autologoff to use ARP ping in deployments where hosts are directly connected.
MAC Address Checking for Autologoff

You can configure SSG to check the MAC address of a host each time that SSG performs an ARP ping.
If SSG finds that the MAC address of the host has changed, SSG automatically initiates the logoff of
that host.
SSG Autologoff Using ICMP Ping

The ICMP is a network-layer Internet protocol that reports errors and provides other information
relevant to IP packet processing. An ICMP ping is the echo message and echo-reply message used to
check for connectivity between devices.
When SSG autologoff is configured to use the ICMP ping mechanism, SSG pings the host to check
connectivity until an ICMP response (successful ping) is obtained or the allowable number of tries is
used up. If all the tries are used up and the ping was unsuccessful, SSG initiates logoff for that host.
Pinging occurs once every configured interval.
As with ARP ping, if any data traffic to or from the host is found during the interval, SSG will not ping
the host because reachability was established by the data traffic.
ICMP ping works in all types of deployments and supports overlapping IP users.
Benefits of SSG Autologoff

The SSG Autologoff feature enables service providers that use SSG to offer subscribers per-minute
billing plans for services. SSG autologoff also prevents subscribers from being charged for periods of
time in which they were not active.
SSG MAC address checking enables service providers that use SSG to prevent a malicious host from
spoofing the IP address of a logged-on host and accessing the logged-on host’s services. The MAC
address-checking functionality allows service providers to prevent SSG host session reuse when a
Dynamic Host Configuration Protocol (DHCP) server assigns the same IP address to a second host
because the first host released its IP address (through either a lease-time expiration or an explicit DHCP
release), but did not log off from SSG.
SSG Session Timeout and Idle Timeout

In a dialup networking or bridged (non-PPP) network environment, a user can disconnect from the
network access server (NAS) and release the IP address without logging out from SSG. Potentially, the
NAS could assign the same IP address to another user. In this kind of instance, SSG continues to allow
traffic to pass from that IP address. SSG provides two mechanisms to prevent this problem from
occurring:

78-17497-01 261
How to Configure SSG to Log Off Subscribers
• Session-Timeout—An attribute that specifies the maximum length of time for which a host or
connection can remain continuously active.
• Idle-Timeout—An attribute that specifies the maximum length of time for which a session or
connection can remain idle before it is disconnected.
User Session-Timeout and Idle-Timeout can be present in the user-profile RADIUS attributes and can
be configured globally. When present, these attributes are applied to each user session and supersede the
global configuration.
Service Session-Timeout and Idle-Timeout are configured in the service profile and apply individually
to each service connection.
The Idle-Timeout and Session-Timeout attributes in the profile are standard RADIUS attributes as
described in RFC 2865.

• Configuring SSG Autologoff, page 262
• Configuring Global SSG Session Timeouts and Idle Timeouts, page 263
• Troubleshooting SSG Subscriber Logoff, page 264
Configuring SSG Autologoff

To configure SSG to automatically log off hosts that have lost connectivity with SSG, perform the steps
in this section.
Restrictions
The following restrictions apply to the SSG Autologoff feature:
• You should use only ARP ping in deployments in which all hosts are directly connected (on Layer
2) to SSG through a broadcast interface such as an Ethernet interface or a bridged interface such as
a routed bridge encapsulation or integrated routing and bridging (IRB) interface. You can use
Internet Control Message Protocol (ICMP) ping in all types of deployment.
• ARP ping works only on hosts that have a MAC address. So, for example, ARP ping does not work
for PPP users because they do not have a MAC table entry.
• ARP ping does not support overlapping users’ IP addresses.
• SSG autologoff that uses the ARP ping mechanism does not work for hosts that have static ARP
entries.
• You can use only one method of SSG autologoff at a time: ARP ping or ICMP ping.
• Session reuse is not prevented if a malicious host performs a MAC address spoof.
SUMMARY STEPS
1. ssg auto-logoff arp [match-mac-address] [interval seconds]

2. ssg auto-logoff icmp [timeout milliseconds] [packets number] [interval seconds]

262 78-17497-01
DETAILED STEPS

Step 1 ssg auto-logoff arp [match-mac-address] [interval Configures SSG to automatically log off hosts and to
seconds] use the ARP ping mechanism to detect connectivity.
Example:
Router(config)# ssg auto-logoff arp
match-mac-address interval 60
Step 2 ssg auto-logoff icmp [timeout milliseconds] [packets Configures SSG to automatically log off hosts that
number] [interval seconds] have lost connectivity with SSG and to use the ICMP
ping mechanism to detect connectivity.
Example:
Router(config)# ssg auto-logoff icmp timeout 300
packets 3 interval 60
Configuring Global SSG Session Timeouts and Idle Timeouts

To configure user global session timeouts and idle timeouts, perform the following steps.
Note To configure timeouts specific to RADIUS proxy subscribers, see the “RADIUS Proxy Timers” and
“Configuring Timers for RADIUS Proxy” sections in the “Configuring SSG to Serve as a RADIUS
Proxy” module.
SUMMARY STEPS
1. ssg timeouts
2. idle seconds
3. session seconds
DETAILED STEPS

Step 1 ssg timeouts Enters SSG timeouts configuration mode.
Example:
Router(config)# ssg timeouts

78-17497-01 263

Step 2 idle seconds Sets the global idle timeout.
Example:
Router(ssg-timeouts)# idle 60
Step 3 session seconds Sets the global session timeout.
Example:
Router(ssg-timeouts)# session 60
Troubleshooting SSG Subscriber Logoff

To troubleshoot SSG subscriber logoff, perform the following steps in any order.
SUMMARY STEPS

4. debug ssg data
DETAILED STEPS

Step 1 debug ssg ctrl-errors Displays all error messages for control modules.
Example:
Step 2 debug ssg ctrl-events Displays all event messages for control modules, including
autologoff events.
Example:
Step 3 debug ssg ctrl-packets Displays packet contents handled by control modules.
Example:
Step 4 debug ssg data Displays all data-path packets.
Example:
Router# debug ssg data

264 78-17497-01
Configuration Examples for Configuring SSG to Log Off Subscribers
Configuration Examples for Configuring SSG to Log Off

Subscribers
• SSG Autologoff Using ARP Ping: Example
• SSG Autologoff Using ICMP Ping: Example
• SSG MAC Address Checking for Autologoff: Example
SSG Autologoff Using ARP Ping: Example

The following example shows how to enable SSG autologoff. SSG will use ARP ping to detect
connectivity to hosts.
ssg auto-logoff arp interval 60
SSG Autologoff Using ICMP Ping: Example

The following example shows how to enable SSG autologoff. SSG will use ICMP ping to detect
connectivity to hosts.
ssg auto-logoff icmp interval 60 timeout 300 packets 3
SSG MAC Address Checking for Autologoff: Example

The following example shows how to enable SSG MAC address checking for autologoff:
ssg auto-logoff arp match-mac-address
The following example shows how to enable SSG MAC address checking for autologoff and to specify
an ARP ping interval of 60 seconds:
ssg auto-logoff arp match-mac-address interval 60
The following sections provide references related to disconnecting SSG subscribers and services.
Related Documents

78-17497-01 265
Feature Information for Configuring SSG to Log Off Subscribers

Configuring RADIUS “Configuring RADIUS” chapter in the Cisco IOS Security
Cisco IOS Security Command Reference, Release 12.4
SSG Commands Cisco IOS Service Selection Gateway Command Reference,
Release 12.4
RFCs
RFCs Title
RFC 2865 Remote Authentication Dial In User Service (RADIUS)
Description Link
even more content.

features that were introduced or modified in Cisco IOS Release 12.2(15)B or a later release appear in
the table.

266 78-17497-01
Table 9 Feature Information for Configuring SSG to Log Off Subscribers

SSG Autologoff 12.2(15)B The SSG Autologoff feature supports methods to log
12.3(4)T subscribers out of SSG.
12.4
feature:
• Graceful Logoff, page 260
• Disconnection Through the Web Services Gateways,
page 260
• SSG Autologoff, page 260
• SSG Session Timeout and Idle Timeout, page 261
• Configuring SSG Autologoff, page 262
• Configuring Global SSG Session Timeouts and Idle
Timeouts, page 263
• Troubleshooting SSG Subscriber Logoff, page 264
• SSG Autologoff Using ARP Ping: Example, page 265
• SSG Autologoff Using ICMP Ping: Example, page 265
• SSG MAC Address Checking for Autologoff: Example,
page 265
The following command was introduced by this feature: ssg
auto-logoff arp.

78-17497-01 267

268 78-17497-01
Configuring SSG Accounting
Cisco Service Selection Gateway (SSG) accounting features allow a service provider to decide how to
configure billing and accounting for its users. This module describes how to configure SSG accounting
features including per-host or per-service accounting, broadcast accounting, prepaid service support, and
postpaid tariff switching.
Module History

and configuration, use the “Feature Information for SSG Accounting” section on page 298.
Contents
• Prerequisites for SSG Accounting, page 269
• Information About SSG Accounting, page 269
• How to Configure SSG Accounting, page 286
• Configuration Examples for SSG Accounting, page 296
Prerequisites for SSG Accounting

SSG must be enabled before SSG accounting can be configured.
Information About SSG Accounting

Before you configure SSG accounting functionality, you should understand the following concepts:
• RADIUS Accounting Records Used by SSG, page 270
• Types of SSG Accounting, page 272

78-17497-01 269
• SSG Prepaid Functionality, page 273

• Prepaid Tariff Switching, page 281
• Extended Prepaid Tariff Switching for SSG, page 285
• Postpaid Tariff Switching for SSG, page 285
RADIUS Accounting Records Used by SSG

SSG sends accounting records with the associated attributes to the RADIUS accounting server when the
events described in the following sections occur:
• Account Logon and Logoff, page 270
• Service Logon and Logoff, page 271
Account Logon and Logoff

SSG sends an accounting-request record to the local RADIUS server when a user logs in or out. The
Acct-Status-Type attribute included in the accounting-request record indicates whether the
accounting-request record marks the start (commencement) of the user service or the stop (termination)
of the service.
When a user logs in, SSG sends an accounting-start record to the RADIUS server. When a user logs out,
SSG send an accounting-stop record to the RADIUS server.
Note The Proxy-state attribute is not normally present in both the accounting-start and accounting-stop record.
It is normally found in only one of them.
Example RADIUS Accounting-Start Record Sent by SSG When a User Logs In

This example shows the information contained in a RADIUS accounting-start record.
User-Name = “user1”
Acct-Status-Type = Start
Acct-Authentic = RADIUS
Service-Type = Framed
Framed-Protocol = PPP
NAS-IP-Address = 192.168.0.0
NAS-Port-Type = Virtual
Acct-Session-Id = 00000011 ! The session ID number
Framed-IP-Address = 192.168.0.10 ! The user’s IP address
Acct-Delay-Time = 0
Example RADIUS Accounting-Stop Record Sent by SSG When a User Logs Out
This example shows the information contained in a RADIUS accounting-stop record.
Acct-Status-Type = Stop
Acct-Session-Time = 77
Acct-Terminate-Cause = User-Request

270 78-17497-01
Acct-Session-Id = 00000011 ! The session ID number

Framed-IP-Address = 192.168.0.10 ! The user’s IP address
Acct-Input-Packets = 0 ! Downstream packet counts
Acct-Output-Packets = 0 ! Upstream packet counts
Acct-Input-Octets = 0 ! Downstream byte counts
Acct-Output-Octets = 0 ! Upstream byte counts
Acct-Delay-Time = 0
The Acct-Session-Time attribute indicates the length of session, expressed in seconds. The
Acct-Terminate-Cause attribute indicates the reason for account termination, which can be due to the
following events:
• User-Request
• Session-Timeout
• Idle-Timeout
• Lost-Carrier
Service Logon and Logoff

SSG sends an accounting-start record to the local RADIUS server when a user logs onto a service, and
sends an accounting-stop record when a user terminates a service. The Acct-Status-Type attribute
included in the accounting-request record indicates whether the accounting-request marks the start of
the user service or the end of the service.
Accounting records are sent only to the local RADIUS server unless the service is a proxy service, in
which case they are also sent to a remote RADIUS server.
Example RADIUS Accounting-Start Record for Service Access

This example shows the information contained in an accounting-start record for service access.
Acct-Session-Id = 00000012
Framed-IP-Address = 192.168.2.60 ! User’s IP address
Service-Info = "NService1.com” ! servicename
Service-Info = "Uuser1" ! username-for-service
Service-Info = "TX"
Acct-Delay-Time = 0
Example RADIUS Accounting-Stop Record for Service Termination

This example shows the information contained in an accounting-stop record for service termination.

78-17497-01 271
NAS-Port = 0
Acct-Session-Id = "00000002"
Acct-Input-Octets = 0 ! Downstream packet counts
Acct-Output-Octets = 649 ! Upstream packet counts
Acct-Input-Packets = 0 ! Downstream byte counts
Acct-Output-Packets = 17 ! Upstream byte counts
Framed-IP-Address = 192.168.101.10 ! User’s IP address
Control-Info = "I0;0" ! high_32_dnst_byte;low_32_dnst_byte
Control-Info = "O0;649" ! high_32_upst_byte;low_32_upst_byte
Service-Info = "NService1.com" ! servicename
Service-Info = "Uuser1" username-for-service
Service-Info = "TP"
Acct-Delay-Time = 0
Types of SSG Accounting

This section provides information about RADIUS accounting for SSG and includes the following topics:
• Interim Accounting, page 272
• Per-Host Accounting, page 272
• Per-Service Accounting, page 273
• SSG Accounting Update Interval per Service Feature, page 273
• Broadcast Accounting, page 273
Interim Accounting
The SSG supports interim (intermittent) RADIUS accounting updates between the time that SSG sends
accounting-start and accounting-stop records. The interim accounting records are sent at a configurable
interval, and are valid for both hosts and service connections.
Per-Host Accounting
Per-host accounting is the aggregate of all the connection traffic for a host. SSG does not account for the
following types of traffic:
• Between the host and the default-network.
• To open gardens.
• Redirected by the TCP Redirect feature.
• Permitted by pass-through filters.
Per-host accounting records all other traffic.
By default, SSG sends host and service accounting records. A service provider only interested in host
records can disable service (per-connection) accounting with the ssg accounting per-host command.
The per-host accounting records are sent to the local authentication, authorization, and accounting
(AAA) server configured with the radius-server host command.

272 78-17497-01
Per-Service Accounting
By default, SSG sends host and service accounting records. A service provider only interested in service
records can disable host accounting with the ssg accounting per-host command. Service
Accounting-Stop records can be throttled by using the ssg accounting stop rate-limit command.
SSG Accounting Update Interval per Service Feature

The SSG Accounting Update Interval Per Service feature allows the service provider to configure
different accounting intervals for different services. Without the SSG Accounting Update Interval Per
Service feature, accounting records of all services would be sent at the configured global interval. When
enabled, the SSG Accounting Update Interval Per Service feature has the following effects:
• When SSG accounting is enabled on a router with the ssg accounting command, the accounting
interval parameters configured in a service profile take precedence.
• When service accounting is configured using the ssg accounting command on the router but service
profile accounting is disabled, then the per-service accounting records will not be sent for that
service.
• When service accounting is disabled on the router using the ssg accounting per-host command but
in a service profile where accounting is enabled, then the per-service accounting records will be sent
for that service.
• Interim accounting records can be disabled by setting the interim accounting interval value to 0.
Broadcast Accounting
SSG supports broadcast accounting, which is the ability to send user accounting records to multiple
RADIUS servers. The SSG broadcast accounting feature provides service providers with geographical
redundancy for RADIUS servers, and provides accounting records to partners in wholesale models.
Note Broadcast accounting is not the same as RADIUS server failover: It requires that clones of host
accounting packets are always forwarded to each of the configured servers, not only when the primary
server fails.
SSG Prepaid Functionality

The SSG Prepaid feature allows SSG to immediately check a user’s available credit to allow or disallow
access to certain services. The user's credit is administered by the billing server as a series of quotas
representing either a duration of use (in seconds) or an allowable data volume (in bytes). A quota is an
allotment of available credit.
SSG differentiates prepaid services from postpaid services by the presence of the Service Authorization
vendor-specific attribute (VSA) in the service profile.
Table 10 describes the elements of the Service Authorization VSA.

78-17497-01 273
Table 10 Service Authorization VSA Elements
Subattribute
26 9 251 Service Authorization The value “Z” indicates that
Service-Info authorization is required.
To obtain the first quota for a connection, SSG submits an authorization request to the AAA server. The
AAA server contacts the prepaid billing server, which returns the quota values to SSG. SSG then
monitors the connection to track the quota usage. When the quota runs out, SSG performs
reauthorization. During reauthorization, the billing server may provide SSG with an additional quota if
there is available credit. If no further quota is provided, SSG logs the user off from the service that has
run out of quota.
This section contains the following topics:
• Service Authorization, page 274
• Service Reauthorization, page 276
• Accounting Records and Prepaid Billing, page 276
• Simultaneous Volume- and Time-Based Prepaid Billing, page 277
• SSG Prepaid Idle Timeout, page 277
• SSG Prepaid Reauthorization Threshold, page 279
• SSG Prepaid Redirection on Quota Exhaustion Feature, page 279
• Default Quota for Prepaid Server Failure, page 280
• Benefits of the SSG Prepaid Feature, page 280
Service Authorization
When a user tries to access a service, SSG downloads the service profile. The presence of the “Z” value
in the service profile indicates that this particular service needs to be prepaid, and that SSG must perform
authorization before providing access.
Once a service has been identified as prepaid, SSG generates an Access-Request packet called a Service
Authorization Request. The contents of this type of Access-Request packet are described in Table 11.
Table 11 Contents of Service Authorization Request Packet
Attribute ID Attribute Name Description Notes

1 User-Name Mobile Station (MS) —
user name
2 PAP Password Global service profile —
password
4 NAS IP Address SSG IP address —
6 Service-Type Framed-user —
26 Vendor-Specific Name of service Subattribute ID 251; code N (the
service-name).

274 78-17497-01
Table 11 Contents of Service Authorization Request Packet

31 Calling-Station-ID Mobile Station ISDN The username or MAC address may
Number (MSISDN) appear in this field if the access
technology does not provide an
MSISDN.
44 Acct-Session-ID Session ID —
55 Time-Stamp Time-stamp —
61 NAS-Port-Type Asynchronous —
(value = 0)
The prepaid billing server generally performs quota authorization based on the same key that was used
for authentication. For example, for mobile wireless networks, where the unique key that is used for
authentication is the Calling-Station-ID attribute (attribute 31), the quota authorization would also be
performed using the Calling-Station-ID attribute.
The prepaid billing server responds to the Service Authorization Request packet with an Access-Accept
packet (the Service Authorization Response) that defines the quota parameters for the connection. The
Service Authorization Response is listed in Table 12. Access to the service is provided based on the
presence and contents of the Quota VSA in the Access-Accept packet listed in Table 13.
Table 12 Content of Service Authorization Access-Accept Packet

26 Vendor-Specific Quota Subattribute ID: 253. The value “Q”
indicates that this is the Quota VSA.
Table 13 Quota VSA Elements
Subattribute
26 9 253 Quota Q—Control-Info code for prepaid
Control-Info quota.
T or V—Quota subcode for time or
volume.
Numeric string—Quota value.
Based on the presence and value of quota attributes in the authorization response, SSG will take the
following actions:
• If a nonzero quota is returned in the authorization response, SSG creates a connection to the service
using the initial quota value in seconds for time and bytes for volume.
• If a value of zero in a quota is returned in the authorization response, then the user has insufficient
credit and is not authorized to use that service.
• If the quota attribute is not present in the authorization response, SSG treats the connection as
postpaid.

78-17497-01 275
In the case of volume quota, instead of SSG using a single token, two quota tokens can be allocated to
accommodate the tariff switching functionality.
Service Reauthorization
When the quota for the connection reaches zero, SSG issues a Service Reauthorization Request to the
billing server. For volume-based billing, SSG decrements the volume-based quota until it runs out. For
time-based billing, the connection is allowed to proceed for the quota duration. The Service
Reauthorization Request includes an SSG VSA called Quota Used, which has the same format as the
Quota VSA described in Table 13. The content of the Service Reauthorization Request is described in
Table 14.
Table 14 Contents of Service Reauthorization Request

1 User-Name MS user name —
2 PAP Password Global service profile password —
4 NAS IP Address SSG IP address —
26 Vendor-Specific Name of service Subattribute ID 251; code N
(the service-name).
26 Vendor-Specific Quota Subattribute ID 253.
The Quota Used VSA has the
same format as the Quota
VSA.
31 Calling-Station-ID MSISDN —
44 Acct-Session-ID Session ID —
55 Time-Stamp Time-stamp —
61 NAS-Port-Type Asynchronous (value=0) —
Accounting Records and Prepaid Billing

SSG and the prepaid billing server use start, stop, and interim accounting records to manage a user’s
prepaid services, as described in the following sequence:
1. When the user tries to connect to the service, SSG sends an authorization request to the prepaid
billing server to download the quota.
2. If SSG gets some valid quota, SSG activates the connection and sends an Accounting-Start record.
3. If quota is exhausted during the usage of the connection, SSG sends reauthorization requests.
4. After a configurable period of time, the interim accounting records are sent to the prepaid billing
server.
5. When the user logs out of the service, SSG sends an accounting stop to the prepaid billing server to
indicate that the session has ended. Based on the usage data in the Accounting-Stop record, the
unused quota is sent back to the user’s account by the billing server.

276 78-17497-01
Simultaneous Volume- and Time-Based Prepaid Billing

The Simultaneous Volume- and Time-Based Prepaid Billing feature allows SSG to provide volume- and
time-based tracking on the same connection.
The prepaid billing server allocates quotas in both time and volume. That is, the authorization response
contains both “QT” and “QV” attributes, and SSG is able to monitor the connection on both types. SSG
performs a reauthorization whenever either of these quota types is exhausted. The next
Service-Authorization response packet contains the usage on both of these quota types.
Note Both the time and volume quota parameters must be nonzero.
The simultaneous volume- and time-based prepaid billing feature can interwork with the prepaid
idle-timeout functionality and volume threshold. Table 15 describes the attributes contained in a
Service-Authorization response packet.
Table 15 Contents of Service-Authorization Response Packet
Attribute ID Vendor ID Subattribute ID Attribute Name Type Value

26 9 253 Quota ASCII string “QT seconds”
26 9 253 Quota ASCII string “QV bytes”
SSG Prepaid Idle Timeout

The SSG Prepaid Idle Timeout feature enables SSG to return residual quota to the billing server from
services that a user is logged into but not actively using. The quota that is returned to the billing server
can be applied to other services that the user is actively using.
The SSG Prepaid Idle Timeout feature enables the services described in the following sections:
Residual Quota Return

SSG returns residual quota to the prepaid billing server from services that a user is logged in to but not
actively using. When the inactivity on the service is equal to the idle-timeout value sent in the response,
the unused quota is returned to the prepaid billing server. This unused quota can be applied to the quota
for the services that the user is actively using.
Open a Connection with Zero Quota

When SSG is configured to use the SSG Prepaid Idle Timeout feature, a user’s connection to services
can be open even when the billing server returns a zero quota, but the connection’s status is dependent
on the combination of the quota and the idle timeout value returned. Depending on the connection
service, SSG requests the quota for a connection from the billing server once the user starts using a
particular service, when the user runs out of quota, or after the configured idle timeout value expires.
Portal Page Redirection

A billing server returns a zero quota and a nonzero idle timeout when a user has run out of credit for a
service. The user is then redirected to the portal page to replenish the quota. While the user’s connection
to the original service is retained, any traffic passing through the connection is dropped. This enables a
user to replenish quota without losing connections to services or having to perform additional service
logins.

78-17497-01 277
SSG returns the quota in a reauthorization request and adds a VSA called the Reauthorization Reason
attribute, which verifies that the reauthorization request is to return the quota to the user, and not to query
for more quota. The content of the Reauthorization Reason attribute is described in Table 16.
Table 16 Reauthorization Reason Attributes
Reauthorization Reason Attribute Description

Not present No Reauthorization Reason attribute is sent if
reauthorization is performed because of quota
expiry (time or volume), except for the special
case “QR0.”
QR0 A reauthorization reason QR0 is sent if
reauthorization is performed because of quota
expiry (time) but the user is idle; that is, no user
traffic has been received since the reception of the
preceding Access-Accept packet.
This applies if the preceding Access-Accept
packet for service reauthorization contained:
• The Idle-Timeout attribute with value “0”
• The Volume-Quota (QV or QX) attribute with
value “0”
• The Time-Quota attribute with value “>0”
Reauthorization reason QR0 indicates to the
prepaid server that no new (volume) quota needs to
be allocated; that is, there is no ongoing user
traffic.
QR1 Reauthorization is performed because of idle timer
expiry; that is, no user traffic received was for the
time specified in the Idle-Timeout attribute.
The interworking of idle-timeout and dual-quota functionality with the existing prepaid features is
shown in Table 17.
Table 17 Interworking of Idle-Timeout and Dual-Quota Functionality
QT QV Idle-Timeout SSG Action

— — — SSG opens the connection and considers postpay connection.
No reauthorization is performed.
0 0 0 SSG opens the connection. Reauthorization occurs when user
traffic comes in.
0 0 — SSG closes or does not open the connection.
0 0 >0 SSG opens the connection but blocks user traffic (drops or
redirects). Reauthorization occurs after a time interval equal to
the idle-timeout value.
— 0 >0 SSG opens the connection but blocks user traffic (drops or
redirects). Reauthorization occurs after a time interval equal to
the idle-timeout value.

278 78-17497-01
Table 17 Interworking of Idle-Timeout and Dual-Quota Functionality
QT QV Idle-Timeout SSG Action

0 >0 0 SSG closes or does not open the connection.
0 >0 >0 SSG opens the connection. Reauthorization occurs when QT
or QV is exhausted, or no user traffic for a time interval that is
equal to the idle-timeout value.
>0 >0 >0 SSG opens the connection. Reauthorization occurs when QT
or QV is exhausted, or no user traffic for a time interval that is
equal to the idle-timeout value.
>0 >0 — SSG opens the connection. Reauthorization occurs when QT
or QV is exhausted.
>0 >0 0 SSG opens the connection. Reauthorization occurs when QT
or QV is exhausted.
>0 0 >0 SSG opens the connection but blocks user traffic (drops or
redirects). Reauthorization occurs when QT is exhausted or
after a time interval equal to the idle-timeout value.
>0 0 0 SSG opens the connection. Reauthorization occurs when QT
is exhausted or when user traffic comes in.
SSG Prepaid Reauthorization Threshold

Using the SSG Prepaid Reauthorization Threshold feature, you can configure SSG to reauthorize for
more quota when the quota allopcated to SSG falls below a configurable minimum threshold value. You
can also configure SSG to drop traffic when it is reauthorizing for the connection. This prevents revenue
leaks in the event that the billing server returns a zero quota for the connection.
When the SSG Prepaid Reauthorization Threshold feature is not configured, traffic passed during
reauthorization represents a revenue leak if the billing server returns a zero quota for the user. You can
prevent this type of revenue leak by configuring a threshold value, causing SSG to reauthorize a user’s
connection before the user completely consumes the allocated quota for a service.
If you configure SSG to drop traffic during reauthorization and configure a threshold value, user traffic
continues until the user exhausts the allotted quota. When the allotted quota is used, the traffic is dropped
until SSG receives a reauthorization response.
SSG Prepaid Redirection on Quota Exhaustion Feature

The SSG Prepaid Redirection on Quota Exhaustion feature gives users the opportunity to replenish
prepaid quota while maintaining the current connection. When the prepaid billing server returns a quota
value of 0 and a positive idle-timeout value, SSG redirects the user to a portal page where additional
quota can be purchased. If the user purchases additional quota, the prepaid billing server returns a
positive quota value to SSG, which allows the connection to continue.
Note When SSG redirects a user to a portal page, it maintains the user’s connection to the original service,
although any traffic passing through the connection is dropped. This enables the user to replenish quota
without requiring a subsequent service login, provided that the reauthorization timout has not been
exceeded.

78-17497-01 279
Default Quota for Prepaid Server Failure

SSG can be configured to allocate a default quota when the prepaid server fails to respond to an
authorization request. The default quota for a service is specified in the service profile. SSG stores the
value when the service profile is downloaded from the AAA server. If the prepaid server is not accessible
during initial authorization, SSG allocates the default quota and activates the connection, thus allowing
the prepaid user to connect to the service.
When a default quota expires, SSG attempts to reauthorize the user. If the prepaid server still does not
respond, SSG will allocate another default quota. SSG will allocate multiple default quotas up to a
configured maximum. Once SSG has allocated the configured maximum number of default quotas, no
further default quota allocations will be made, and the user's connection to the service will be terminated.
SSG will also allocate default quotas when the prepaid server fails during the reauthorization of existing
connections. Allocation of a default quota for the reauthorization of an existing connection prevents the
connection from being terminated because of the unavailability of the prepaid server. Table 18 describes
the Prepaid Default Quota VSA.
Table 18 Prepaid Default Quota VSA
Subattribute ID
Attribute ID Vendor ID and Type Attribute Name Subattribute Data
26 9 251 Service-Info Prepaid Default PZQT seconds—sets a default
Quota time quota.
or
PZQVbytes—sets a default
volume quota.
Benefits of the SSG Prepaid Feature

Concurrent Prepaid Service Access
The SSG Prepaid feature can support concurrent prepaid service access while maintaining the same pool
of quota at the prepaid billing server. SSG services can be configured for concurrent or sequential access.
Concurrent access allows users to log in to a service while connected to other services.
Real-Time Billing
The SSG Prepaid feature allows for real-time billing with maximum flexibility, regardless of the type of
service and billing scheme. Users can be billed on a flat rate, air-time, or volume basis.
Redirection Upon Exhaustion of Quota

When a user runs out of quota, SSG can redirect the user to a portal where the user can replenish the
quota without being disconnected from the service.
Returning Residual Quota

The SSG Prepaid Idle Timeout feature enables SSG to return residual quota to the billing server from
services that a user is logged in to but not actively using. The quota that is returned to the billing server
can be applied to other services that the user is actively using.

280 78-17497-01
Threshold Values
The SSG Prepaid Reauthorization Threshold feature can prevent revenue leaks by enabling the user to
configure a threshold value. Configuring a threshold value causes user connections to be reauthorized
before the user completely consumes the allotted quota for a service.
Traffic Status During Reauthorization

Revenue leaks can be prevented by configuring SSG to drop connected traffic during reauthorization of
a service. The user remains connected to the service and need not log in again to the service, but no traffic
is forwarded during the reauthorization process. This prevents users from continuing to use a service for
which they have run out of quota while SSG sends a reauthorization request to the billing server.
Simultaneous Volume- and Time-Based Prepaid Billing

SSG supports rating on both time and volume simultaneously for prepaid services. The prepaid billing
server may allocate quotas in both time and volume, and SSG monitors the connection for either type.
SSG performs a reauthorization whenever either of these quota types is exhausted.
Prepaid Tariff Switching

Prepaid tariff switching allows changes in tariffs during the lifetime of a connection. This feature applies
to volume-based prepaid connections where the tariff changes at certain times of the day.
Typically, a service provider uses prepaid tariff switching to offer different tariffs to a user during an
active connection; for example, changing a user to a less expensive tariff during off-peak hours.
When SSG is monitoring the prepaid connection based on volume, at the tariff switching time, SSG can
switch to the new charging rate. This feature will interoperate with all existing prepaid functionality,
including the idle-timeout feature.
Note SSG is not involved in computing the billing rate changes that occur at tariff switch points.
Billing rate change computations are performed by the prepaid billing server.
SSG supports prepaid tariff switching by using two quota tokens that correspond to the pretariff switch
time period and posttariff switch time period.
In the authorization response, the prepaid billing server specifies the tariff change time and the tokens
for post-switch and pre-switch periods in its authorization response to SSG.
Note The tariff change time denotes the delay, in seconds, between the authorization and the tariff
switch.
SSG uses the prepaid tariff switch quota until the tariff switch occurs. Upon tariff switch, SSG performs
a token switch and starts using the postpaid tariff quota for prepaid connection monitoring.
Reauthorization occurs only when either of these tokens is exhausted, not when a tariff change occurs.
Authorization and Reauthorization Behavior When Prepaid Tariff Switching Occurs

Table 19 describes the behavior of SSG in the various events that occur when prepaid tariff switching
takes place.

78-17497-01 281
Table 19 Authorization and Reauthorization Behavior
Event Action
An authorization response is received Tariff switching is enabled on SSG for a given prepaid
containing the dual-quota token tariff connection.
switch attribute.
During data forwarding, the quota runs SSG performs a reauthorization in the same way as in a no
out before the tariff switch occurs. tariff switching case. The prepaid billing server may
recalculate the tariff switch time and send the response
again. Note that tariff switch attributes are not included in
the reauthorization response.
During data forwarding, the tariff switch SSG switches from the current quota token to the second
time elapses after the last authorization. quota token. The new quota token is now used for real-time
accounting.
During data forwarding, the quota runs SSG will send the quota usage in pre- and posttariff periods
out after the tariff switch. back to the prepaid server in the authorization response.
The user logs out of the service after the SSG will report the quota usage in the pre- and posttariff
tariff switch. switch periods in the Accounting Stop packet.
The user logs out of the service before SSG sends a normal Accounting-Stop packet, as in the
the tariff switch. nontariff switching case.
Interim accounting If the connection is in the posttariff switch period, SSG will
report quota usage in the pre- or posttariff switching periods
in the interim accounting packet.
SSG Prepaid Tariff Switching VSAs

The VSA shown in Table 20 is used in authorization and reauthorization responses to send quota tokens
and the tariff switch time. Table 20 describes the VSA content.
Table 20 Content of VSA Used in Authorization/Reauthorization Response Packets
Subattribute
26 9 253 Quota Q—Control-Info code for prepaid quota.
Control-Info
X—Tariff switch code for prepaid quota.
time;—Tariff switch time, in seconds.
volume;—Preswitch quota volume token,
in bytes.
volume— Postswitch quota volume
token, in bytes.
The VSA shown in Table 21 is used in reauthorization requests and accounting packets. This VSA is
used in addition to the usual Quota Volume attribute that indicates the total volume usage in a
connection. Table 21 describes the VSA content.

282 78-17497-01
Table 21 Content of VSA Used in Reauthorization Requests and Accounting Packets
Subattribute
26 9 253 Quota Q—Control-Info code for prepaid quota.
Control-Info
B;—Tariff switch code for denoting the
total volume used after the last tariff
switch.
volume—Total volume of traffic in that
connection (since start) after the last tariff
switch, in bytes.
time—Tariff switch time in the UNIX
time stamp. This is used only in postpaid
service accounting records.
Interim Accounting Updates for SSG Prepaid Tariff Switching

The interim accounting records contain the cumulative usage information (since start of connection) and
the amount of usage after the last tariff switch time. The Accounting-Stop record contains the total usage
information and the volume of traffic sent after the last tariff switch.
Note Only one interim accounting record in every tariff switching interval plus an Accounting-Stop
record is required for the billing server to reconstruct the usage information before and after the
switching time.
The following example illustrates how the accounting interim updates would look in various tariff switch
periods and how the billing server has to interpret the records to obtain the individual usages in the
various intervals.
Consider a user logged in to the connection at time T0. The tariff switch points in that week are Tx, Ty,
and Tz. The user logs off at T1.
Accounting records A1 through A5 were sent in the various tariff switching intervals. All interim
accounting records contain the total volume of traffic sent in the connection from start until that point in
time. This volume of traffic value is available in the standard accounting attributes and the SSG
Accounting VSAs. For records sent after a tariff switch, the tariff switch VSA indicates usage since the
last tariff switch point.
Accounting record A1 does not contain any tariff switch VSAs. Accounting record A2 contains a tariff
switch VSA to indicate the usage since the last tariff switch point (Tx). Note that more than one interim
accounting record can be sent in the interval, depending on the accounting interval configured. It is
possible to derive the usage in the various intervals even if only one accounting record in an interval was
successfully sent. The following sequence shows how the billing server calculates usage in the interval
between Tx and Ty.
Record A2 contains total volume (V2) and usage since the last tariff switch point Tx (T2). The amount
of usage in interval (T0,Tx) is represented as V(0,x) = V2 – T2.
Record A3 contains total volume (V3) since start of connection, and the last tariff switch point Ty (T3).
The amount of usage in interval (T0,Ty) is represented as V(0,y) = V3 – T3. The amount of usage in
interval (Tx,Ty) is represented as V(x,y) = V(0,y) – V(0,x).

78-17497-01 283
Note Accounting-Stop record A5 also contains only the total volume and the usage since the last tariff switch
point, and not the usage in the various intervals.
The information in these interim accounting records enables the service provider to derive the
accounting information in the various tariff switching intervals.
Dual Quota and Idle-Timeout Prepaid Tariff Switching

The dual quota functionality also interworks with the tariff switching functionality. Instead of the QV
and QT attributes being present in the authorization response, QX and QT attributes can be present
together in the authorization response. In this case, reauthorization is done whenever the time quota runs
out and either of the two volume quota tokens runs out in its respective period. Table 22 describes the
attributes contained in a response to a service reauthorization request.
Table 22 Contents of Service Reauthorization Response Packet
Attribute Vendor Subattribute Status Attribute Name Type Subattribute Data

ID ID ID
28 Optional Idle-Timeout Integer Idle Timeout
26 9 253 Optional Quota ASCII QT seconds
string
26 9 253 Mandatory Quota-for-Tariff ASCII QX seconds;
Switching string bytes; bytes
Tariff quota is considered to be exhausted when prepaid tariff quota (PRE) is exhausted before tariff
switching, or when the postpaid tariff (POST) quota is exhausted after tariff switch. The interworking of
dual quota functionality with tariff switching and idle-timeout is shown in Table 23.
Note In Table 23, QT represents time-based quota, and QX represents quota for prepaid and postpaid tariff
switching. TS denotes time of tariff switch, PRE denotes prepaid switch quota, and POST denotes
postpaid switch quota. QXTS;PRE;POST represents QX time-of-tariff-switch; prepaid-switch-quota;
postpaid-switch-quota.
Table 23 Interworking of Dual-Quota Functionality with Idle-Timeout
QT QXTS;PRE;POST Idle-Timeout SSG Action

0 >0;0;0 0 SSG opens the connection. Reauthorization occurs when
user traffic comes in.
0 >0;0;0 >0 SSG opens the connection but blocks user traffic (drop or
redirect). Reauthorization occurs after a time interval
equal to the idle timeout value.
0 Any combination 0 or >0 SSG closes or does not open the connection.
not covered by
idle-timeout equal
to or greater than 0

284 78-17497-01
Table 23 Interworking of Dual-Quota Functionality with Idle-Timeout
QT QXTS;PRE;POST Idle-Timeout SSG Action

>0 >0;>0;>0 >0 SSG opens the connection. Reauthorization occurs when
the time-based quota (QT) or the prepaid quota (PRE) is
exhausted before tariff switching, or when the prepaid
(PRE) and postpaid (POST) quotas are exhausted, or when
no user traffic occurs for a time interval equal to the
idle-timeout value.
>0 >0;>0;0 >0 SSG opens the connection. Reauthorization occurs when
QT or PRE is exhausted before tariff switching when tariff
switching occurs, or when no user traffic occurs for a time
interval equal to the idle-timeout value.
>0 >0;>0;>0 0 SSG opens the connection. Reauthorization occurs when
QT is exhausted or PRE is exhausted before tariff
switching, or when the sum of PRE and POST tariff is
exhausted.
>0 >0;>0;0 0 SSG opens the connection. Reauthorization occurs when
QT is exhausted or when tariff quota is exhausted.
>0 >0;0;0 0 SSG opens the connection. Reauthorization occurs when
QT is exhausted or when user traffic comes in.
If dual quota was allotted in the earlier authorization, the reauthorization request contains both the
volume and time attributes. The volume attributes may include the quota for tariff switching (QB) or the
volume-based quota (QV) when the connection is made in the post-tariff switch period. The
reauthorization reason attribute may be present in the reauthorization request. Table 16 on page 278
describes the reasons.
Extended Prepaid Tariff Switching for SSG

The Extended Prepaid Tariff Switch for SSG feature is used to measure the usage of specific services at
various times, even when the monetary value of the volume quota does not change at the time of tariff
switching. In such a scenario, the remaining amount of a user’s prepaid tariff switch quota continues as
postpaid tariff switch quota. Information can be collected about how much quota was used before a
particular time and how much was used after, providing a usage profile of specific services at various
times.
For instance, say that gaming and stock trading services are offered. Using the Extended Prepaid Tariff
Switch feature, the user could purchase quota that could be used for each service at the same flat rate.
Gaming traffic may be higher in the evenings, for example, while stock trading may be in more demand
during business hours. The resulting usage profile can help you decide whether to charge a premium for
specific services at specific times.
Postpaid Tariff Switching for SSG

The Postpaid Tariff Switching for SSG feature allows changes in tariffs during the lifetime of a
connection. This feature applies to volume-based postpaid connections where the tariff changes at
certain times of the day.

78-17497-01 285
How to Configure SSG Accounting
Typically, a service provider uses postpaid tariff switching to offer different tariffs to a user during an
active connection; for example, changing a user to a less expensive tariff during off-peak hours.
To handle tariff switches for postpaid connections, the accounting packets log the usage information
during the various tariff switch intervals. The service profile contains a weekly tariff switch plan
detailing the times of day at which tariff changes occur. SSG monitors the usage at every tariff switch
point and records this information in the interim accounting records. The billing server monitors all
accounting interim updates and obtains the information about the volume of traffic sent at each tariff
rate.
Note Tariff switching is not required for time-based billing services. Because the billing server knows the
service login time stamp and logout time stamp, it can calculate the different tariffs that apply during
that time.

This section describes how to configure SSG accounting features and contains the following tasks:
• Configuring SSG Accounting, page 286
• Configuring SSG Broadcast Accounting, page 287
• Configuring SSG Prepaid Features, page 288
• Configuring Postpaid Tariff Switching for SSG, page 295

Perform this task to enable enable SSG accounting.
Prerequisites for Configuring SSG Accounting

The RADIUS server must be configured and operational before you configure SSG accounting.
SUMMARY STEPS
1. ssg accounting [per-host] [per-service] [interval seconds]

2. ssg accounting stop rate-limit [records]

286 78-17497-01
DETAILED STEPS

Step 1 ssg accounting [per-host] [per-service] Enables SSG accounting and specifies the interval at which
[interval seconds] accounting updates are sent to the accounting server.
• To enable the sending of per-host accounting records
Example: only, use the per-host keyword.
Router(config)# ssg accounting per-host
interval 60 • To enable the sending of per-service accounting records
only, use the per-service keyword
Step 2 ssg accounting stop rate-limit [records] Limits the rate of accounting records sent per second.
• The value can be set between 10 and 5000.
Example:
Router(config)# ssg accounting stop rate-limit
200
Configuring SSG Broadcast Accounting

SSG broadcast accounting requires the configuration of a broadcast group. Perform this task to send host
accounting records to multiple servers.
Note This is not the same as RADIUS server failover. It clones accounting packets, which are then always
forwarded to each of the configured servers, not only when the primary server fails.
SUMMARY STEPS

2. server ip-address auth-port auth-port-number acct-port acct-port-number
4. server ip-address auth-port auth-port-number acct-port acct-port-number
5. aaa accounting network accounting-list-name start-stop broadcast group group-name group
group-name

78-17497-01 287
DETAILED STEPS

Step 1 aaa group server radius group-name Defines the server group.
Example:
Router(config)# aaa group server radius BILLING
Step 2 server ip-address auth-port auth-port-number Configures a server in the selected server group.
acct-port acct-port-number
Example:
Router(config)# server 10.10.50.181 auth-port
1812 acct-port 1813
Step 3 aaa group server radius group-name Defines the server group.
Example:
Router(config)# aaa group server radius
HOTSTANDBY
Step 4 server ip-address auth-port auth-port-number Configures a server in the selected server group.
acct-port acct-port-number
Example:
Router(config-sg)# server 10.10.50.180 auth-port
1812 acct-port 1813
Step 5 aaa accounting network accounting-list-name Configures a broadcast accounting network list.
start-stop broadcast group group-name group
group-name • The accounting-list-name argument must be
ssg_broadcast_accounting.
Example:
Router(config)# aaa accounting network
ssg_broadcast_accounting start-stop broadcast
group BILLING group HOTSTANDBY
Configuring SSG Prepaid Features

• Configuring SSG Prepaid Features on the Router, page 288
• Configuring RADIUS Service Profiles for the SSG Prepaid Support Feature, page 290
• Redirecting TCP Traffic for SSG Prepaid Quota Refill, page 290
• Verifying Configuration of the SSG Prepaid Feature, page 292
Configuring SSG Prepaid Features on the Router

Perform this task to configure SSG prepaid features on the router.

288 78-17497-01
Prerequisites for SSG Prepaid Features
SSG accounting must be enabled in order for the SSG Prepaid features to be used. SSG accounting is
enabled by default. If it has been disabled, enable it by using the ssg accounting command in global
configuration mode.
Restrictions for SSG Prepaid Features
• Quotas are measured in seconds for time or bytes for volume. There is no way to change the unit of
measure.
• The volume quota is for combined upstream and downstream traffic.
• Returning quota when the connection is idle is supported only for volume-based connections. It is
not supported for time-based connections.
SUMMARY STEPS
1. radius-server attribute 44 include-in-access-req

2. radius-server attribute 55 include-in-acct-req
3. ssg aaa group prepaid server-group
4. ssg prepaid threshold [time seconds]
5. ssg prepaid threshold [volume bytes]
6. ssg prepaid threshold default-quota [number-of-times]
7. ssg prepaid reauthorization drop-packet
8. radius-server vsa send authentication
9. radius-server vsa send accounting
DETAILED STEPS

Step 1 radius-server attribute 44 include-in-access-req Sends RADIUS attribute 44 (Accounting Session ID) in
Access-Request packets for quota authorization, and
enables the sending of this attribute in user authentication
Example:
Router(config)# radius-server attribute 44
requests.
include-in-access-req
Step 2 radius-server attribute 55 include-in-acct-req Sends RADIUS attribute 55 (Event-Timestamp) in
accounting packets.
Example:
Router(config)# radius-server attribute 55
include-in-acct-req
Step 3 ssg aaa group prepaid server-group (Optional) Specifies the server group to be used for SSG
prepaid authorization.
Example: • If the server group is not configured, SSG will send
Router(config)# ssg aaa group prepaid prepaid requests to the local AAA server, which then
ssg_prepaid parses the prepaid authorizations and
reauthorizations.

78-17497-01 289

Step 4 ssg prepaid threshold [time seconds] (Optional) Sets the prepaid threshold time in seconds.
• SSG performs a reauthorization when a user’s quota
Example: reaches this threshold.
Router(config)# ssg prepaid threshold time 100
Step 5 ssg prepaid threshold [volume bytes] (Optional) Sets the prepaid threshold volume in bytes.
SSG performs a reauthorization when a user’s quota
matches this byte value.
Example:
Router(config)# ssg prepaid threshold volume 100
Step 6 ssg prepaid threshold default-quota (Optional) Specifies the number of times that SSG will
[number-of-times] allocate the default quota when the prepaid server is
unreachable.
Example:
Router(config)# ssg prepaid threshold
default-quota 26
Step 7 ssg prepaid reauthorization drop-packet (Optional) Configures SSG to drop prepaid traffic during
reauthorization if threshold values are not configured.
Example:
Router(config)# ssg prepaid reauthorization
drop-packet Note When threshold values are configured, traffic is
dropped during reauthorization after a user
completely exhausts the allotted quota and before
SSG gets a reauthorization response from the
billing server.
Step 8 radius-server vsa send authentication Configures the network access server to send VSAs in an
authentication request to the RADIUS server.
Example:
Router(config)# radius-server vsa send
authentication
Step 9 radius-server vsa send accounting Configures the network access server to send VSAs in an
accounting request to the RADIUS server.
Example:
Router(config)# radius-server vsa send accounting
Configuring RADIUS Service Profiles for the SSG Prepaid Support Feature
To configure support of the SSG Prepaid feature, you must add the following vendor-specific attributes
to RADIUS profiles:
• Service Authorization (Z) attribute
• Prepaid Server (PZS) attribute
• Prepaid Accouting Interval (PZI) attribute
Redirecting TCP Traffic for SSG Prepaid Quota Refill

Perform this task to configure SSG to redirect a user's TCP traffic to a prepaid portal when the user runs
out of quota on the billing server.

290 78-17497-01
Prerequisites
The SESM Captive Portal feature must be configured on the appropriate port to listen for redirect
requests.
SUMMARY STEPS
1. ssg tcp-redirect
4. Repeat Step 3 to add servers to the captive portal group.
5. end
6. redirect prepaid-user to server-group-name
DETAILED STEPS

Step 1 ssg tcp-redirect Sets the server group and server used for quota refill
redirection.
Example:
Step 2 server-group group-name Defines the group of one or more servers that make up a
named captive portal group and enters
SSG-redirect-group configuration mode.
Example:
Router(config-ssg-redirect)# server-group • group-name—Name of the captive portal group.
myserver group
Router(config-ssg-redirect-group)# server
192.168.10.10 port 1
• port—TCP port of the server to add to the captive
portal group.
Step 4 Repeat Step 3 to add servers to the captive portal group. —
Step 5 end Exits SSG-redirect-group configuration mode.
Example:
Router(config-ssg-redirect-group)# end
Step 6 redirect prepaid-user to server-group-name Configures a captive portal group for redirection of
prepaid user traffic.
Example: • server-group-name—Name of the captive portal
Router(config-ssg-redirect)# redirect group.
prepaid-user to myserver

78-17497-01 291
Verifying Configuration of the SSG Prepaid Feature

This optional task explains how to verify the configuration and operation of the SSG Prepaid feature.
The commands contained in the task steps can be used in any sequence and may need to be repeated.
SUMMARY STEPS

DETAILED STEPS
Step 1 Enter the show ssg connection command to display information about the host’s connection to the
specified service, including quota information for prepaid connections.
The following output is displayed for a user that has a nonzero volume quota with a nonzero idle timeout:
Router# show ssg connection 172.16.0.0 Internet

User Name:quser
Owner Host:172.16.0.0
Associated Service:Internet
Connection State:0 (UP)
Connection Started since:*01:45:09.000 GMT Thu Oct 9 2003
User last activity at:*01:45:09.000 GMT Thu Oct 9 2003
Prepaid quota:
Quota Type = ‘Volume’, Quota Value = 11200
Timeout Value = 60
Session policing disabled
The following output is displayed for a user that has a zero volume quota with zero idle timeout:

User Name:quser
Prepaid quota:
Quota Type = 'VOLUME', Quota Value = 0
Timeout Value = 0

292 78-17497-01
The following output is displayed when a user receives a time quota:

User Name:quser
Prepaid quota:
Quota Type = 'TIME', Quota Value = 30
The following output is displayed when a user receives a zero time quota with idle timeout:

User Name:quser
Prepaid quota:
Quota Type = 'TIME', Quota Value = 0
Timeout Value = 60
Step 2 Enter the show ssg service command to display the redirect group configured for a service:
Router# show ssg service Internet
------------------------ ServiceInfo Content -----------------------

Uplink IDB: gw:10.0.0.0
Name:Internet
Type:PASS-THROUGH
Mode:CONCURRENT
Service Session Timeout:0 seconds
Service Idle Timeout:0 seconds
Service refresh timeleft:102 minutes
Authorization Required ! Indicates a prepaid service
Authentication Type:CHAP
Reference Count:1
DNS Server(s):
No Radius server group created. No remote Radius servers.
Prepaid Redirect Service Group = InternetRedirectGroup !
Service-specific redirect group
Included Network Segments:

172.16.0.0/255.255.0.0
Excluded Network Segments:
ConnectionCount 1

78-17497-01 293
Full User Name not used
Domain List:
Active Connections:
1 :RealIP=10.0.0.0, Subscriber=172.18.0.2
------------------------ End of ServiceInfo Content ----------------
Step 3 Enter the show ssg tcp-redirect group command to display the configured redirect server groups. The
output displayed shows two configured redirect groups. The redirect default group called
“DefaultRedirectGroup” is used to redirect prepaid connections when a user runs out of quota, and the
corresponding service is not configured with any service-specific redirect group:
Router# show ssg tcp-redirect group

InternetRedirectGroup
DefaultRedirectGroup
! The default redirect group is used to redirect prepaid connections when the user runs
out of quota and the corresponding service is not configured with any service-specific
redirect group.
Unauthenticated user redirect group:None Set

Default service redirect group:None Set
Prepaid user default redirect group:DefaultRedirectGroup
SMTP forwarding group:None Set
Default initial captivation group:None Set
Default advertising captivation group:None Set
Step 4 Enter the show running-config command to display the contents of the current running configuration:
Router# show running-config
.
.
.
ssg prepaid reauthorization drop-packet
ssg prepaid threshold volume 2000
ssg prepaid threshold time 10
.
.
.
ssg tcp-redirect
server-group InternetRedirectGroup
server 255.255.255.253 8080
server 255.255.255.100 80
!
server-group DefaultRedirectGroup
server 10.0.0.1 8080
server 10.0.0.20 80
!
redirect prepaid-user to DefaultRedirectGroup
.
.
.

294 78-17497-01
Configuring Postpaid Tariff Switching for SSG

Perform this task to configure the Postpaid Tariff Switching for SSG feature.
Post-Paid VSA
SSG uses VSA 26 in the service profile to specify the tariff switch points. Table 24 describes the contents
of this VSA.
Table 24 Post-Paid VSA Content
Subattribute
26 9 251 post-paid P—Service-Info code for postpaid
Service-Info service.
W—Service-Info code for weekly tariff
switch plan.
weekly time—Weekly tariff switch time
in hh:mm:ss:d format.
• hh = hour of day <0-23>
• mm = minutes <0-59>
• ss = seconds <0-59>
• d = bitmap format for the days of the
week. Each weekday is represented
by one bit, as follows:
– 00000001 = Monday
– 00000010 = Tuesday
– 00000100 = Wednesday
– 00001000 = Thursday
– 00010000 = Friday
– 00100000 = Saturday
– 01000000 = Sunday
SUMMARY STEPS
1. Add the Post-Paid VSA (attribute 26) to the service profile using the parameters listed in Table 24.
DETAILED STEPS

Step 1 Add the Post-Paid VSA (attribute 26) to the service Specifies the tariff switch points for postpaid tariff
profile using the parameters listed in Table 24. switching.

78-17497-01 295
Configuration Examples for SSG Accounting
Examples
The following example shows the configuration of the Service Profile Definition to support a daily fee.
The tariff switch will occur each midnight.
SSG Service-Info = "PPW00:00:00:127"
The following example show the configuration of the Service Profile Definition to support an off-peak
tariff in which a tariff switch occurs Monday through Friday at 8:00 p.m.:
The following example shows the configuration of the Service Profile Definition to support an on-peak
tariff in which a tariff switch occurs Monday through Friday at 6:00 a.m.:
Configuration Examples for SSG Accounting

• Accounting Update Interval per Service in RADIUS: Example, page 296
• Basic Prepaid Configuration: Examples, page 297
• TCP Redirect for Prepaid Users: Example, page 297
• Configuring Prepaid Threshold Value: Examples, page 297
Accounting Update Interval per Service in RADIUS: Example

In the following example, the interim accounting interval for the RADIUS service profile named
proxy_ser is set at 90 using the L90 attribute:
user = proxy_ser{
check_items= {
2=cisco
}
reply_attributes= {
9,251="TX"
9,251="R10.10.0.0;255.255.0.0"
9,251="S255.255.255.253;1645;1646;cisco;2;0"
9,251="L90"
28=600
}
}
}
In the following example, the local profile cisco.com is configured on the router to send an interim
accounting update every 90 seconds:
Router(config)# local-profile cisco.com
Router(config-prof)# attribute 26 9 1 "L90"

296 78-17497-01
Basic Prepaid Configuration: Examples

The following example shows how to configure SSG to provide basic prepaid billing services:
The following example show a service profile configured to support a prepaid service:
ExampleProfile Password = "servicecisco", Service-Type = Outbound
Service-Info = "IVideo Jam",
Service-Info = "R10.10.10.0;255.255.255.0",
Service-Info = "D10.10.10.10",
Service-Info = "Omy-video.net",
Service-Info = "MS",
Service-Info = "Z"
TCP Redirect for Prepaid Users: Example

The following example shows how to configure a captive portal group called PrepaidRedirectGroup, add
two servers to PrepaidRedirectGroup, and redirect prepaid users to the newly created captive portal:
ssg enable
ssg tcp-redirect
server-group PrepaidRedirectGroup
server 10.0.0.1 8080
server 10.0.0.20 80
end
redirect prepaid-user to PrepaidRedirectGroup
Configuring Prepaid Threshold Value: Examples

The following example shows how to configure a threshold time value of 10 seconds:
ssg prepaid threshold time 10
The following example shows how to configure a threshold volume value of 2000 bytes:
ssg prepaid threshold volume 2000
The following example shows how to configure SSG to drop traffic during reauthorization:
ssg prepaid reauthorization drop-packet
The following sections provide references related to the SSG Accounting feature.

78-17497-01 297
Feature Information for SSG Accounting
Related Documents
Configuring RADIUS “Configuring RADIUS” chapter in the Cisco IOS Security Configuration Guide,
Release 12.4
Cisco IOS Security Command Reference, Release 12.4
Description Link
Technical Assistance Center (TAC) home page, containing http://www.cisco.com/public/support/tac/home.shtml
30,000 pages of searchable technical content, including
links to products, technologies, solutions, technical tips,
and tools. Registered Cisco.com users can log in from this
page to access even more content.

features that were introduced or modified in Cisco IOS Releases 12.2(4)B or later appear in the table.
specific commands was introduced, see the command reference documents.

298 78-17497-01
Table 25 Feature Information for SSG Accounting

Software
Extended Prepaid Tariff Switching for SSG 12.3(14)T The Extended Prepaid Tariff Switch for SSG feature is used
12.4 to measure the usage of specific services at various times,
even when the monetary value of the volume quota does not
change at the time of tariff switching.
feature:
• Extended Prepaid Tariff Switching for SSG, page 285
Postpaid Tariff Switching for SSG 12.2(16)B The Postpaid Tariff Switching for SSG feature allows
12.3(4)T changes in tariffs during the lifetime of a connection.
12.3(14)T The following section provides information about this
12.4 feature:
• Postpaid Tariff Switching for SSG, page 285
• Configuring Postpaid Tariff Switching for SSG,
page 295
SSG Accounting 12.0(3)DC The SSG Accounting feature allows a service provider to
12.2(4)B decide how to configure billing and accounting for its users.
12.2(16)B feature:
12.3(4)T
12.3(14)T • RADIUS Accounting Records Used by SSG, page 270
12.4 • Types of SSG Accounting, page 272
SSG Accounting Update Interval Per Service 12.2(13)T The SSG Accounting Update Interval Per Service feature
allows the service provider to configure different
accounting intervals for different services.
feature:
• SSG Accounting Update Interval per Service Feature,
page 273
• Accounting Update Interval per Service in RADIUS:
Example, page 296
SSG Default Quota for Prepaid Billing Server 12.3(11)T The SSG Default Quota for Prepaid Billing Server Failure
Failure feature enables SSG to be configured to allocate a default
quota when the prepaid server fails to respond to an
authorization request.
The following section provide information about this
feature:
• Default Quota for Prepaid Server Failure, page 280

78-17497-01 299
Table 25 Feature Information for SSG Accounting (continued)

Software
SSG Prepaid Enhancements 12.2(16)B The SSG Prepaid Enhancements feature adds support for
12.3(4)T prepaid tariff switching, postpaid tariff switching, and
12.3(14)T simultaneous volume- and time-based prepaid billing to the
12.4 existing SSG Prepaid feature.
feature:
• Configuring Prepaid Threshold Value: Examples,
page 297
SSG Prepaid Idle Timeout 12.2T The SSG Prepaid Idle Timeout feature enables SSG to
12.3(4)T return residual quota to the billing server from services that
a user is logged into but not actively using.
feature:
• SSG Prepaid Idle Timeout, page 277
SSG Prepaid Tariff Switching 12.2(4)B The SSG Prepaid Tariff Switching feature allows changes in
12.2(11)T tariffs during the lifetime of a connection.
feature:
• Configuring Prepaid Threshold Value: Examples,
page 297
SSG Suppression of Unused Accounting Records 12.2T The SSG Suppression of Unused Accounting Records
12.3(4)T feature allows you to turn off unneeded Service Selection
Gateway (SSG) accounting records.
feature:
• Types of SSG Accounting, page 272

300 78-17497-01
RADIUS Profiles and Attributes for SSG
This module describes RADIUS profiles and their attributes.
Module History

and configuration, use the “Feature Information for RADIUS Profiles and Attributes for SSG” section
on page 357.
Contents
Prerequisites for RADIUS Profiles and Attributes for SSG, page 301
Information About RADIUS Profiles and Attributes for SSG, page 301
Additional References, page 356
Prerequisites for RADIUS Profiles and Attributes for SSG

Before you can configure SSG to authenticate subscribers you must first configure SESM and the
RADIUS server to support the logon method.
Information About RADIUS Profiles and Attributes for SSG

• RADIUS Profiles for SSG Support, page 301
• RADIUS Accounting Records for SSG, page 348
RADIUS Profiles for SSG Support


78-17497-01 301
• SSG Vendor-Specific Attributes, page 302

• Subscriber Profiles, page 329
• Service Profiles, page 332
• Service Group Profiles, page 341
• Pseudo-Service Profiles, page 342
• Examples of SSG RADIUS Profiles, page 345
SSG Vendor-Specific Attributes

Table 26 lists vendor-specific attributes used by SSG. By sending an Access-Request packet with the
vendor-specific attributes shown in the table, SESM can send requests to SSG to log on and log off an
account and disconnect and connect services. The vendor ID for all of the Cisco-specific attributes is 9
Table 26 Vendor-Specific Attributes
AttributeID VendorID SubattributeID SubattributeName SubattributeDataType

26 9 1 Cisco-AVpair String
Attributes
26 9 250 SSG Account-Info String
Attributes
26 9 251 SSG Service Info String
Attributes
26 9 253 SSG Control Info String
Attributes
The following sections describe the format of each subattribute.
Note All RADIUS attributes are case sensitive.
Cisco-AVpair Attributes
The Cisco-AVpair attributes are used in user and service profiles to configure ACLs and L2TP
.
Downstream Specifies either a Cisco IOS standard access control list or an extended access
Access Control List control list to be applied to downstream traffic going to the user.
(outacl)
Upstream Access Specifies the secret (the password) used for L2TP tunnel authentication.
Control List
Upstream Access Specifies either a Cisco IOS standard access control list or an extended access
Control List (inacl) control list to be applied to upstream traffic coming from the user.

302 78-17497-01
VPDN IP Address Specifies the IP addresses of the home gateways (LNSes) to receive the L2TP
connections.
VPDN IP Address Specifies the name of the tunnel that must match the tunnel ID specified in the
LNS VPDN group.
SSG Account-Info Attributes
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.
RADIUS Freeware Format Example

Account-Info = “Nservice1.com”
CiscoSecure ACS for UNIX Format Example

9,250 = “Nservice1.com”
The following account-info attributes set various parameters for the host in SSG.
Table 28 SSG Account Information Attributes
Subattribute Value Attribute Function Description

A Auto Log On Service Automatically logs a user into a service
when the user logs in to SSG.
D Default Internet Access Specifies whether a host is allowed to
default Internet access. Not currently
used by SSG.
G Group Name Used by SESM to display the group name
and the list of services in the group.
M Messaging IP and Port Specifies the IP address and port number
of the messaging server for a host.
N Service Name Specifies the name of the service that a
host is subscriber to.
P Primary Service Name Tells SSG that this is the Auto-domain
service. Not currently used by SSG.
Q Subscriber QoS Info Specifies the QoS parameters for the host
in both the upstream and downstream
directions.
R TCP Redirection Specifies the TCP Redirection
configuration for the host
S Subscriber IP Identifies the host on SSG.

78-17497-01 303

TP Transparent Pass-through (TP) Specifies the Transparent pass-through
Info (TP) user for Transparent Autologon
(TAL).
V User Cookie The AAA server sends this attribute to
SSG in the user profile.
S SESM Namespace Contains subattributes that are used by
SESM to form the complete IDs for the
host or connections.
Auto Log On Service

This attribute specifies the name of the service that the user is automatically logged onto after an
Account-Logon. This is configured in the user profile and is present in Access-Accept packets and can
appear multiple times.
code: 250, 'A'

len: 3
+-+-+-+-+-+-+-+-+-+-+
|a|b| c |d|e|f|g|
+-+-+-+-+-+-+-+-+-+-+
a = 26 (RADIUS attr for vendor specific)

b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 250 (Subattribute ID for Account-Info)
e = len (length of the vendor specific subattribute)
f = 'A' (account-info code for Auto log on service)
g = <service name[;user;password]>
Default Internet Access

This attribute specifies if a host is allowed default Internet access. This is currently not used by SSG.
code: 250, 'D'

len: 4
+-+-+-+-+-+-+-+-+-+-+
|a|b| c |d|e|f|g|
+-+-+-+-+-+-+-+-+-+-+

304 78-17497-01

f = 'D' (account-info code for default Internet Access)
g = 'D'/'E' (disable or enable default Internet Access)
Group Name
This attribute specifies the service-group Name. This is used in cases where the services are grouped
under one group-name and the user just subscribes to the service-group. this attribute is primarily used
by SESM to display group-name and then the list of services in that group.
code: 250, 'G'

len: > 7
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
|a|b| c |d|e|f|g |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+

f = 'G' (account-info code for service-group-name)
g = <service-group-name as string>
Messaging IP and Port

This attribute specifies the IP address and port number of the messaging server for a host. SSG sends
asynchronous notifications to this host whenever the state of a host changes. This is present in the
Access-request for Account-logon from SSD. The newer versions of the SSD, i.e., SESM do not use this
attribute.
code: 250, 'M'

len: > 7

78-17497-01 305
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
|a|b| c |d|e|f|g |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+

f = 'M' (account-info code for messaging ip and port)
g = <ip:port> ip is in dot notation
Service Name
This attribute specifies the name of the service that a host is subscribed to. This is configured in the user
profile and is present in Access-Accept packets and can appear multiple times.
This attribute is also used in Access-Accept packets for Account-Query by SESM to indicate the status
of the user’s connection to a service and includes the elapsed time of the connection and the username
used to logon to that service. It is also used in Access-Accept for Service-Query from SESM.
code: 250, 'N'

len: > 6
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
|a|b| c |d|e|f|g |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+

f = 'N' (account-info code for service name)
for account info reply:

g = <name;description;flag>
(the flag is 'P', 'X' or 'T' representing the service type)

306 78-17497-01
for service query reply:

g = <[1|0]name;elapsed time;service username>
for account ping reply:

g= <1;servicename;elapsed-time in seconds;username;downstream packets;upstream
packets;downstream bytes;upstream bytes>
Primary Service Name

This attribute is used in conjunction with auto-domain. It tells SSG that this is the auto-domain service
– where the user needs to be authenticated. Currently not used by SSG.
code: 250, 'P'

len: > 6
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
|a|b| c |d|e|f|g |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+

f = 'P' (account-info code for Primary Service Name)
g = <service-name as a string>
Subscriber QoS Info

This attribute specifies the QoS parameters for the host in both the upstream and downstream direction.
This is configured in the user profile and is present in Access-Accepts and can appear only once.
code: 250, 'Q'

len: > 6
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
|a|b| c |d|e|f|g |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+


78-17497-01 307

f = 'Q' (QoS-info code for subscriber IP)
g = <U;cir;normal burst;excess burst;D;cir;normal burst;excess burst>
‘U’ indicates upstream parameters and ‘D’ indicates downstream parameters.
TCP Redirection
This attribute specifies the TCP-redirection configuration for the host. It has three subattributes, one for
SMTP redirection, one for initial captivation and one for periodic advertising captivation. This is
configured in the user profile and is present in the Access-Accept and each subattribute can appear at
most once.
code: 250, 'R'

len: >3
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
|a|b| c |d|e|f|g |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+

f = 'R' (account-info code for redirect features… see below)
g = one of the allowable additional features described in the following sections.
SMTP forwarding
g = 'S' indicating user has SMTP forwarding capability
If SMTP forwarding has been enabled on a per-user basis, the presence of this attribute in the user profile
allows SMTP forwarding for that host to the server defined on SSG.
Initial Captivation
g = 'I<group>;<duration>[;<service>]'
This attribute indicates that the user has Initial Captivation capability, and also indicating captive portal
group to use, and duration of the captivation (in seconds). If the optional service field is added then the
captivation will only start once the user has activated the named service.

308 78-17497-01
Advertisement Captivation
g = 'A<group>;<duration>;<frequency>[;<service>]'
This attribute indicates that the user has Advertisement Captivation capability, and also indicating
captive portal group to use, and duration and approximate frequency of the captivation (in seconds). If
the optional service field is added then the captivation will only occur when the user has the named
service active.
Subscriber IP
This attribute identifies the host on SSG. This is present in all Access-Requests from SESM to SSG and
also in all the replies from SSG to SESM. In the normal mode, the IP address is used to identify the host.
In the port-bundle host-key mode, a combination of the IP address and the port-bundle is used.
code: 250, 'S'

len: > 6
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
|a|b| c |d|e|f|g |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+

f = 'S' (account-info code for subscriber IP)
g = <subscriber's IP in dot notation>[:<port bundle number>]
port bundle number is used in Host-Key mode
Transparent Pass-through (TP) Info

This attribute specifies the Transparent Pass-through (TP) user for Transparent Auto-Logon (TAL). This
is configured in the user profile and is present in Access-Accepts and can appear only once.
code: 250, 'TP'

len: > 6
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
|a|b| c |d|e|f|g |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+


78-17497-01 309

f = 'TP' (Transparent Pass-through for TAL)
User Cookie
This attribute is used by AAA-server – which is sent transparently by SSG to the aaa-server in all
accounting records. AAA-server initially sends this attribute in the user-profile. In a sense, this is similar
to class attribute (attribute#25)
code: 250, 'V'

len: > 6
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
|a|b| c |d|e|f|g |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+

f = 'V' (account-info code for user cookie)
g = <cookie as string>
SESM Namespace
This is used by SESM. It has subattributes that are used to form the complete IDs for host or connections.
This attribute has the following generic format:
Code: 250, $
Len: >12
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
|a|b| c |d|e|f| g | h |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
A = 26 (RADIUS code for vendor-specific Attribute>

B = Len (Length of the RADIUS vendor-specific Attribute>
C = 9 (Cisco’s Vendor ID)
D = 250 (Subattribute ID for SSG Account-Info)

310 78-17497-01
E = len (Length of the vendor-specific subattribute)

F = ‘$’ (Account-Info code for SESM namespace)
G = ‘…’ Sub-code for SESM namespace account-info code
H = value The value of the relevant Complete ID key.
Host Complete ID
The possible values for the host complete ID are described in Table 29 below.
Note The host name, host IP address and host MSISDN will be sent using the standard RADIUS attributes.
Table 29 Host Compete ID Attributes
Attribute Sub-Code Possible Values

Client IP Address Using the standard RADIUS The address field is four octets.
attribute #8– Framed-IP-Address
Client MAC Address MA A string containing the client’s MAC
Address (in the format
“0123.4567.89a0”). This attribute is only
present for directly connected clients.
Sub-Interface SI A string containing the name of the
downlink interface for the client.
VPI/VCI VP A string containing the VPI/VCI values.
This attribute is only present for PPP or
RBE interfaces.
MSISDN Using the standard RADIUS A string field containing the MSISDN of
attribute #31 – a client. This attribute is only present for
Calling-Station-ID RADIUS proxy clients.
.Connection Complete ID
The connection complete ID attribute has the following format:
Code: 250, $
Len: >12
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|a|b| c |d|e|f|g| h |i|
+-+-+-+-+-+-+-+-+-+-+-+-+-+
a = 26 (RADIUS code for vendor-specific Attribute>

b = Len (Length of the RADIUS vendor-specific Attribute>
c = 9 (Cisco's Vendor ID)

78-17497-01 311
d = 250 (Subattribute ID for SSG Account-Info)

e = len (Length of the vendor-specific subattribute)
f = '$' (Account-Info code for SESM namespace)
g = 'C' (Connection-info sub-code)
h = ' ' sub-code for connection-info (IP/UN/ID)
i = value of the relevant parameter in the format
<servicename>;<value>
The possible values for the connection complete ID are listed in Table 30.
Attribute Sub-Code Possible Values

Connection Username UN <servicename>;<username>
Username contains the name used during
service logon to <servicename>.
Calling ID ID <servicename>;<calling-id>
The calling-id contains the calling ID
used during service logon.
Connection Real IP IP <servicename>;<real IP>
Address
The Real IP address used for NAT in SSG
can be assigned by the proxy service
AAA server of by the LNS for L2TP
services.
Example:
For a connection to "service1" with the username "usernam1", calling-id
"1234567" and real IP 10.10.0.1, the attribute values would be as follows:
Account-Info 250, "$CUNservice1;user1"

Account-Info 250, "$CIDservice1;123456"
Account-Info 250, "$CIPservice1;10.1.1.1"
SSG Service Info Attributes
The Service-Info VSAs are used for SSG service specific parameters and are configured in the service
profile. These attributes appear in Access-Accept packets for service profile download.
The following Service Info attributes set various parameters for the host in SSG.

312 78-17497-01
Table 31 SSG Service Info Attributes

A Authentication Type Defines the authentication type, PAP or
CHAP, for the proxy and tunnel service.
B MTU for SSG L2TP Service Specifies the MTU for an L2TP tunnel
service.
C Auto-Domain Service NAT Specifies whether the Auto-domain
service needs to apply NAT.
D DNS Server Address Sets the DNS server IP address for the
service.
E Max Connections Limits the number of connections to a
particular service.
F Attribute Filter Lists the RADIUS attributes to be filtered
from user authentication.
G Service Next Hop Gateway Sets the next hop gateway for SSG.
H Initial URL Used by SESM to open a page with this
URL.
K TCP-Redirect Server-Group Specifies TCP-redirect server groups.
L Accounting Update Interval Sets the accounting interval for interim
accounting for connections to this
service.
M Service Mode Specifies the mode of access to a service.
N Service Name for Quota Values Specifies the name of the service.
O Service Domain Specifies the domains that are part of the
service.
P Payment Type Defines further subattributes relating to
prepaid and postpaid services.
Q Service QoS Info Sets the upstream and downstream QoS
parameters for a connection to the
service.
R Destination Network Specifies the networks that belong to the
service.
S RADIUS Server Specifies the RADIUS server to be used
for authentication for the service.
T Service Type Specifies the type of service.
U Service User Name Specifies the username in connection
accounting requests.
V Service Defined Cookie For Specifies a cookie string fro a service.
Proxy RADIUS
X Enable Full User Name for Appends the service name to the
Proxy RADIUS username during authentication to the
service.

78-17497-01 313
Authentication Type
This attribute defines the authentication type – PAP or CHAP - for the proxy and tunnel service.
code: 251, 'A'

len: 4
+-+-+-+-+-+-+-+-+-+-+
|a|b| c |d|e|f|g|
+-+-+-+-+-+-+-+-+-+-+

d = 251 (Subattribute ID for Service-Info)
f = 'A' (service-info code for PPP Authentication Type)
g = 'P'/'C' (PAP or CHAP)
MTU for SSG L2TP Service

This attribute specifies the MTU for a L2TP tunnel service. This is configured in the tunnel service
profile and can appear almost at once.
code: 251, 'B'

len: > 3
+-+-+-+-+-+-+-+-+-+-+-+-+...-+
|a|b| c |d|e|f| g |
+-+-+-+-+-+-+-+-+-+-+-+-+...-+

f = 'B' (service-info code for MTU for SSG l2tp service)
g = <non-zero MTU as a string>

314 78-17497-01
Auto-Domain Service NAT

This attribute tells if the auto-domain service needs to have NAT applied or not. The auto-domain service
provides an ip-address: this attribute dictates whether to use this attribute or to assign an ip-address from
local pool and use NAT.
code: 251, 'C'

len: = 10
+-+-+-+-+-+-+-+-+-+-+-+-+...-+
|a|b| c |d|e|f| g |
+-+-+-+-+-+-+-+-+-+-+-+-+...-+

f = 'C' (service-info code for auto-domain service NAT)
g = [0|1]
DNS Server Address

This attribute sets the DNS server IP address for the service. Two DNS servers, primary and secondary,
can be specified using this attribute. This is configured in the service profile and can appear almost at
once.
code: 251, 'D'

len: > 7
+-+-+-+-+-+-+-+-+-+-+-+-+...-+
|a|b| c |d|e|f| g |
+-+-+-+-+-+-+-+-+-+-+-+-+...-+

f = 'D' (service-info code for service DNS)
g = <ip1[;ip2]> (IP of the Primary/Secondary DNS servers in dot notation)

78-17497-01 315
Max Connections
This value of this attribute limits the number of connections to a particular service.
code: 251, 'E'

len: > 9
+-+-+-+-+-+-+-+-+-+-+...-+
|a|b| c |d|e|f|p| g |
+-+-+-+-+-+-+-+-+-+-+...-+

b = len (length of the RADIUS vendor-specific)
d = 253 (subattribute ID for Service-Info)
e = len (length of the vendor-specific filter)
p = 'E' (service-info code for max connections)
g = <number in ascii string format>
Attribute Filter
This attribute lists the RADIUS attributes that are to be filtered out from user authentication for the
service (would apply to both proxy RADIUS service and L2TP tunnel service).Currently only attribute
31 (calling station ID) is supported. The attributes listed here are filtered in Access-Request for proxy
service authentication, L2TP tunnel session negotiation and SSG proxy service connection
Accounting-Requests sent to the remote AAA (AAA server specified in the proxy service profile). This
filter has no effect on host accounting requests, prepaid (re)authorization requests and connection
accounting requests to the local AAA server. This attribute can be used when the access provider does
not wish to expose the user’s calling-ID/MSISDN number to services.
code: 251, 'F'

len: > 12
+-+-+-+-+-+-+-+-+-+-+...-+
|a|b| c |d|e|f|p| g |
+-+-+-+-+-+-+-+-+-+-+...-+


316 78-17497-01
p = 'F' (Port filter indication flag)

g = <attribute number>
The ‘g’ parameter contains an ASCII string of the attribute to be filtered. Initially only a value of ‘31’
is allowed to filter out calling station id.
Service Next Hop Gateway

This attribute sets the next-hop gateway for the SSG service. This attribute is configured in the service
profile and can appear almost at once. The string specified in this attribute is used to key off a next-hop
table on SSG to find the next-hop gateway IP address. This attribute can appear almost at once. If this
attribute is not configured, the service name is used as the key to find the next-hop IP address.
code: 251, 'G'

len: > 7
+-+-+-+-+-+-+-+-+-+-+-+-+...-+
|a|b| c |d|e|f| g |
+-+-+-+-+-+-+-+-+-+-+-+-+...-+

f = 'G' (service-info code for service next hop gateway)
g = <IP in dot notation or service name>
Note Service name will be resolved to IP from the next hop table.
Initial URL
This attribute is used by SESM.When the user logs into the service, SESM opens up a page with this
URL.
code: 251, 'H'

len: > 7
+-+-+-+-+-+-+-+-+-+-+-+-+...-+
|a|b| c |d|e|f| g |
+-+-+-+-+-+-+-+-+-+-+-+-+...-+

78-17497-01 317

f = 'H' (service-info code for initial-URL)
g = <uri as a string>
TCP-Redirect Server-Group
This attribute specifies service-specific tcp-redirect server-groups. Currently, it is used only for the
per-service web-proxy server-group.
code: 251, 'K'

len: > 7
+-+-+-+-+-+-+-+-+-+-+-+-+....-+
|a|b| c |d|e|f|g| h |
+-+-+-+-+-+-+-+-+-+-+-+-+....-+

f = 'K' (service-info code for tcp-redirect server-group)
g = 'W' (service-info sub-code for per-service web-proxy server-group)
h = <server-group name as a string>
Accounting Update Interval

This attribute sets the accounting interval for interim accounting for connections to this service. This
attribute can be present almost at once. If this attribute is not configured in the service profile, the global
SSG accounting interval configured in SSG is used.
code: 251, 'L'

len: > 7
+-+-+-+-+-+-+-+-+-+-+-+-+...-+
|a|b| c |d|e|f| g |
+-+-+-+-+-+-+-+-+-+-+-+-+...-+

318 78-17497-01

f = 'L' (service-info code for accounting update interval)
g = <seconds as a string>
Service Mode
This attribute specifies the mode of access to a service. If the mode is sequential, a user cannot access
this service if they are already logged on to another service. If the user is logged on to a sequential
service, no other service can be accessed. This attribute can appear almost at once. If this attribute is not
configured in the service profile, the default mode for the service is concurrent.
code: 251, 'M'

len: 4
+-+-+-+-+-+-+-+-+-+-+
|a|b| c |d|e|f|g|
+-+-+-+-+-+-+-+-+-+-+

f = 'M' (service-info code for service mode)
g = 'S'/'C'/'E' (Sequential, Concurrent or Exclusive)
Service Name for Quota Values

This attribute specifies the name of the service. This is not configured in the service profile. It is present
in Access-Requests from SSG for pre-paid service authorization.
code: 251, 'N'

len: 4
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
|a|b| c |d|e|f| g |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+

78-17497-01 319

f = 'N' (service-info code for service name)
g = <service name>
Service Domain
This attribute specifies the domains that are a part of the service. If a user is connected to this service,
all DNS queries to this domain are redirected to the DNS server for this service. This attribute is
configured in the service profile and can appear multiple times.
code: 251, 'O'

len: > 4
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
|a|b| c |d|e|f| g |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+

f = 'O' (service-info code for domain name)
g = <domain name[;domain name[;...]]> (domain name or names separated by semicolon)
Payment Type
This attribute is used as a code to define further subattributes relating to prepaid and postpaid services.
code: 251, 'P'

len: 3
+-+-+-+-+-+-+-+-+-+-+-+
|a|b| c |d|e|f|g|…|
+-+-+-+-+-+-+-+-+-+-+-+

320 78-17497-01

f = 'P' (service-info code for payment type)
g=’P’ or ‘Z’ (P denotes code for postpaid subattributes, Z denotes code for prepaid subattributes)
Postpaid Services - Weekly Tariff Plan

The weekly tariff plan for postpaid services is specified using the following attribute.
code: 251, 'P'

len: > 12
+-+-+-+-+-+-+-+-+-+-+-....-+
|a|b| c |d|e|f|g|h| i |
+-+-+-+-+-+-+-+-+-+-+-....-+

b = len(length of the RADIUS vendor-specific)
d = 251 (subattribute ID for SSG Service-Info)
e = len (length of the vendor-specific Attribute>
f = ‘P’ (service-info code for service payment type)
g = ‘P’ (service-info code for postpaid service)
h = ‘W’ (service-info code for weekly tariff switch plan specification)
i = <weekly time> Weekly tariff switch time is in hh:mm:ss:d format:
hh = hour of day <0-23>
mm = minutes <0-59>
ss = seconds <0-59>
d = bit-map format for the days of week.
The format of the "d" attribute within the "QW" attribute of a service profile allows the configuration of
arbitrary combinations of days where each weekday is represented by one bit. For example:
00000001 = Monday
00000010 = Tuesday
00000100 = Wednesday
00001000 = Thursday
00010000 = Friday
00100000 = Saturday
01000000 = Sunday

78-17497-01 321
Consequently the value "00011111" (= 31 decimal) defines Monday, Tuesday, Wednesday, Thursday and
Friday.
Example:
SSG Service-Info = "PPW00:00:00:127" - tariff switch time each day a week at midnight to support
daily fee
SSG Service-Info = "PPW20:00:00:31" - tariff switch Monday till Friday at 8:00pm (off peak tariff)
SSG Service-Info = "PPW06:00:00:31" - tariff switch Monday till Friday at 6:00am (on peak tariff)
Service QoS Info

This attribute sets the upstream and downstream QoS parameters for a connection to the service. This
attribute is configured in the service profile and can appear almost at once.
code: 251, 'Q'

len: > 6
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
|a|b| c |d|e|f| g |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+

f = 'Q' (QoS-info code for Service)
g = <U;cir;normal burst;excess burst;D;cir;normal burst;excess burst>
‘U’ Upstream QoS parameters, ‘D’ downstream QoS parameters
Destination Network
This attribute specifies the networks that belong to a service. The network can be either an include
network or an exclude network. Users are not allowed to access exclude networks. This is configured in
the service profile and should be present at least once.
code: 251, 'R'

len: > 12
+-+-+-+-+-+-+-+-+-+-+-+...-+
|a|b| c |d|e|f| g |
+-+-+-+-+-+-+-+-+-+-+-+...-+

322 78-17497-01

f = 'R' (service-info code for destination network)
g = <ip;mask[;flag]>
(ip and mask are in dot notations, flag can be 'I' for INCLUDED or 'E' for EXCLUDED; flag is default
to 'I')
Note Within one RADIUS packet, there may be multiple instances of service-info subattributes for the
destination network.
RADIUS Server
This attribute specifies the RADIUS server to be used for authentication for the service. This is used only
for proxy services. Using multiple instances of this attribute can be used to configure multiple servers.
code: 251, 'S'

len: > 7
+-+-+-+-+-+-+-+-+-+-+-+-+...-+
|a|b| c |d|e|f| g |
+-+-+-+-+-+-+-+-+-+-+-+-+...-+

f = 'S' (service-info code for RADIUS server)
g = <ip>;<auth port>;<acct port>;<secret>
Service Type
This attribute specifies the type of the service. A service can one of ‘Proxy’, ‘Passthrough’ or ‘Tunnel’
type. The default type of a service is ‘Passthrough’ if this attribute is not set in the service profile.
code: 251, 'T'

len: 4
+-+-+-+-+-+-+-+-+-+-+

78-17497-01 323
|a|b| c |d|e|f|g|
+-+-+-+-+-+-+-+-+-+-+

f = 'T' (service-info code for service type)
g = 'X'/'T'/'P' (Proxy, Tunnel or Passthrough)
Service User Name

This attribute specifies the username in connection Accounting requests. The Accounting requests to the
local AAA server contain the host’s username, while the Accounting requests to the remote AAA server
for proxy services contain the username that the user used to logon to the service.
code: 251, 'U'

len: 4
+-+-+-+-+-+-+-+-+-+-+
|a|b| c |d|e|f|g|
+-+-+-+-+-+-+-+-+-+-+

f = 'U' (service-info code for service user name)
g = <user name>
Note Note: Currently, only Connection Accounting packet uses this subattribute.
Service Defined Cookie For Proxy RADIUS

This attribute specifies a cookie string for a service. This string is sent in all Access-Requests for
authentication for a connection and also in all Accounting-Requests for the connections to this service.
This attribute is configured in the service profile and can be appear almost at once.
code: 251, 'V'

324 78-17497-01
len: >=4
+-+-+-+-+-+-+-+-+-+-+
|a|b| c |d|e|f|g|
+-+-+-+-+-+-+-+-+-+-+

f = 'V' (service-info code for service defined cookie)
g = <service defined cookie>
Enable Full User Name for Proxy RADIUS

If this attribute is set for a service, the service name is appended to the username during authentication
to the service as ‘username@servicename’. This attribute is configured in a service profile and can
appear almost at once.
code: 251, 'X'

len: 3
+-+-+-+-+-+-+-+-+-+
|a|b| c |d|e|f|
+-+-+-+-+-+-+-+-+-+

f = 'X' (service-info code for service defined cookie)
SSG Control Info Attributes
The following SSG Control Info attributes set various parameters for the host in SSG.

78-17497-01 325
Table 32 SSG Control Info Attributes

F Filter (that is, Port Filtering) Currently not used by SSG.
F Both Source and Destination Currently not used by SSG.
Filters (that is, Port Filtering)
G Next Hop Gateway Table Entry In a next hop table profile, associates a
next hop key with an IP address.
T Input Bytes Count Indicates the input bytes. Is only used in
accounting packets.
O Output Bytes Count Indicates the output bytes. Is only used in
accounting packets.
Filter (that is, Port Filtering)

This is currently not used by SSG. The Cisco generic VSAs for ACLs are used instead.
code: 253, 'F'

len: > 12
+-+-+-+-+-+-+-+-+-+-+...-+
|a|b| c |d|e|f|p| g |
+-+-+-+-+-+-+-+-+-+-+...-+

g = <ip:portlist;mask;flag;filterID>
Note The portlist can be a list of port numbers delimited by ",". "-" can be used to specify a range. For
example, a port list consists of 23, 34, 35, and all the ports that are greater than 3000 can be specified as
"23,34-35,3001-".
Both Source and Destination Filters (that is, Port Filtering)

This is currently not used by SSG. The Cisco generic VSAs for ACLs are used instead.
code: 253, 'F'

len: > 12

326 78-17497-01
+-+-+-+-+-+-+-+-+-+-+...-+-+...-+
|a|b| c |d|e|f|p| g | h |
+-+-+-+-+-+-+-+-+-+-+...-+-+...-+

g = <src ip:src portlist;mask;>
h = <dst ip:dst portlist;mask;flag;filterID>
Note The portlist can be a list of port numbers delimited by ",". "-" can be used to specify a range. For
example, a port list consists of 23, 34, 35, and all the ports that are greater than 3000 can be specified as
"23,34-35,3001-". The flag is either 'D' for deny or 'P' for permit.
Next Hop Gateway Table Entry

This attribute is used in a next-hop table profile to associate a next-hop key with an IP address. The keys
are used in the service profile’s Next-hop gateway attribute. This attribute can appear multiple times to
create a Next Hop Gateway Table. Each SSG can have a Next Hop Gateway Table defined, and each
service can reference entries in this table by using the Service-Info Next Hop Gateway attribute.
code: 253, 'G'

len: > 12
+-+-+-+-+-+-+-+-+-+-+...-+
|a|b| c |d|e|f|p| g |
+-+-+-+-+-+-+-+-+-+-+...-+

b = len (length of the RADIUS vendor-specific>
p = 'G' (Next Hop Gateway Entry Flag)
g = <key;ip> (key can be any string; ip is the corresponding next hop gateway IP in dot notation)

78-17497-01 327
Input Bytes Count

This attribute is used to indicate the number of input bytes and is used in accounting packets only. For
this attribute to be sent in an accounting request by SSG, the aaa accounting send vsa command should
be enabled on SSG.
code: 253, 'I'
len: > 12
+-+-+-+-+-+-+-+-+-+-+...-+
|a|b| c |d|e|f|p| g |
+-+-+-+-+-+-+-+-+-+-+...-+

p = 'I' (Input Bytes Count Flag)
g = <HI;LOW> (Formula to calculate exact byte count is HI*4294967296 + LOW)
Output Bytes Count

This attribute is used to indicate the number of output bytes and is used in accounting packets only. For
this attribute to be sent in an accounting request by SSG, you should enable the aaa accounting send
vsa command on SSG.
code: 253, 'O'

len: > 12
+-+-+-+-+-+-+-+-+-+-+...-+
|a|b| c |d|e|f|p| g |
+-+-+-+-+-+-+-+-+-+-+...-+

p = 'O' (Output Bytes Count Flag)
g = <HI;LOW> (Formula to calculate exact byte count is HI*4294967296 + LOW)

328 78-17497-01
Note This attribute is for accounting packets only.
Subscriber Profiles
RADIUS subscriber profiles contain a password, a list of subscribed services and groups, and access
control lists.
Table 33 describes attributes that appear in RADIUS user profiles.
Table 33 Subscriber Profile Attributes
Cisco AV Pair 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
Auto Service (Reply attribute) Automatically logs a user in to a
service when the user logs in to SSG.
Home URL (Optional) The URL for the user’s preferred
Internet home page.
Service Group (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.
Service Name (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
Framed-IP-Netmask 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.
Idle-Timeout (Reply attribute) Specifies, in seconds, the
maximum length of time for which a connection
can remain idle.
Password (Check attribute) Specifies the user’s password.
Session-Timeout (Reply attribute) Specifies, in seconds, the
maximum length of the user’s session.
1. Standard attributes are described in detail in RFC 2138.

78-17497-01 329
Downstream Access Control List
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.
Syntax Description

Example
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
Upstream Access Control List
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.
Syntax Description

Example
for the same ACL. Multiple attributes are downloaded according to the number specified and
Auto Service
The Auto Service attribute subscribes the user to a service and automatically logs the user in to the
service when the user accesses SESM. A user profile can have more than one Auto Service attribute.
Account-Info = "Aservicename[;username;password]"

330 78-17497-01
Syntax Description
servicename Name of the service.

username Username used to access the service. Required for proxy services.
password Password used to access the service. Required for proxy services.
Example
Account-Info = “Afictiousname.net;jdoe;secret"
Note The user must be subscribed to this service.
Home URL
The Home URL attribute specifies the URL for the user’s preferred Internet home page. This attribute is
optional.
Account-Info = "Hurl"
or
Account-Info = "Uurl"
Syntax Description
url A fully qualified URL for the user’s preferred Internet home page.
Usage
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:
• Hurl—URL for the home page displayed in a frame in the SESM browser window.
• Uurl—URL for the home page displayed in its own browser window.
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.
Example
Account-Info = "Uhttp://www.fictiousname.com"
Service Group
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.
Account-Info = "Gname"
Syntax Description
name Name of the group profile.

78-17497-01 331
Example
Account-Info = "GServiceGroup1"
Note Multiple instances of this attribute can occur within a user or service-group profile. Use one
attribute for each service subgroup.
Service Name
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.
Account-Info = "Nname"
Syntax Description
name Name of the service profile.

Account-Info = "Ncisco.com"
CiscoSecure ACS for UNIX Example

9,250="cisco.com"
Note Multiple instances of this attribute can occur within a user or service profile. Use one attribute
for each service.
Service Profiles
Service profiles define the services that subscribers can select. Each service that is accessible has a
profile that defines the attributes of the service. Service profiles are configured on the RADIUS server
or directly on SSG. The RADIUS server or SESM downloads the service profiles to SSG as needed.
Service profiles include the following information: password, service type (outbound), type of service
(passthrough or proxy), service access mode (sequential or concurrent), DNS server IP address,
networks that exist in the service domain, access control lists, and timeouts. The following sections
describe the attributes included in RADIUS service profiles.
Specifies either an IOS standard access control list or an extended access control list to be applied to
downstream traffic going to the user.
Cisco-AVpair = “ip:outacl [#number]={standard-access-control-list |
extended-access-control-list}”
Syntax Description


332 78-17497-01
Example
Specifies either an IOS standard access control list or an extended access control list to be applied to
upstream traffic coming from the user.
Cisco-AVpair = “ip:inacl[#number]={standard-access-control-list |
extended-access-control-list}”
Syntax Description

Example
L2TP Tunnel Password
Specifies the secret (the password) used for the L2TP tunnelauthentication.
Cisco-AVpair = "vpdn:tunnel-password=secret"
Syntax Description
secret Secret (password) for L2TP tunnel authentication.
RADIUS Freeware Format:: Example

Cisco-AVpair = "vpdn:l2tp-tunnel-password=cisco"
CiscoSecure ACS for UNIX: Example

9,1 = "vpdn:l2tp-tunnel-password=cisco"
VPDN IP Address
Specifies the IP addresses of the home gateways (LNSes) to receive the L2TP connections.

78-17497-01 333
Cisco-AVpair =
"vpdn:ip-addresses=address1[<delimiter>address2][<delimiter>address3]..."
Syntax Description
address IP address of the home gateway.

<delimiter> , (comma) Selects load sharing among IP addresses.
(space) Selects load sharing among IP addresses.
/ (slash) 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).

Cisco-AVpair = "vpdn:ip-addresses=10.1.1.1,10.2.2.2,10.3.3.3/10.4.4.4,10.5.5.5"

9,1 = "vpdn:ip-addresses=10.1.1.1,10.2.2.2,10.3.3.3/10.4.4.4,10.5.5.5"
VPDN Tunnel ID
Specifies the name of the tunnel that must match the tunnel ID specified in the LNS VPDN group.
Cisco-AVpair = "vpdn:tunnel-id=name"
Syntax Description
name Tunnel name.

Cisco-AVpair = "vpdn:tunnel-id=My-Tunnel"

9,1 = "vpdn:tunnel-id=My-Tunnel"
L2TP Hello Interval
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.
Cisco-AVpair = "vpdn:l2tp-hello-interval=interval"
Syntax Description
interval Interval at which hello keepalive packets are sent, in seconds.

Cisco-AVpair = "vpdn:l2tp-hello-interval=2"

334 78-17497-01

9,1 = "vpdn:l2tp-hello-interval=2"
attribute filter
Some services require the MSISDN to be hidden from the service provider. To support this capability,
you can add an attribute filter to the service profile. You can specify the attributes to be filtered from
authentication and accounting records sent to the remote AAA server.
The SSG Service-Info VSA lists the RADIUS attributes to filter from user authentication for the service;
this capability applies to both proxy RADIUS service and L2TP tunnel service. At present you can only
filter attribute 31 (Calling Station ID).
The Calling Station ID is filtered only from connection authentication for proxy and L2TP tunnel
services and for connection accounting records sent to the remote AAA server.
Table 34 shows the format of the Service-Info VSA needed to enable attribute filtering.
Table 34 SSG Service-Info VSA Descriptions
Attribute ID Vendor ID Subattribute ID Attribute Name Subattribute Data

26 9 250 Service-Info The value F is the filter indication flag
and should be set as F31.
Table 35 lists the attributes used for service logon with and without the MSISDN and with MSISDN
filter set to F31.
Table 35 Service Logon Comparison (With MSISDN, Without MSISDN, and With MSISDN
Filter)
Connection Connection
Service Connection Accounting to Accounting to Prepaid Prepaid
Logon Authentication1 Local AAA Remote AAA2 (Re)authorization Accounting
Without Host Calling ID Host Calling ID Host Calling ID Host Calling ID Host Calling ID
MSISDN
With Connection Host Calling ID Connection Host Calling ID Host Calling ID

MSISDN3 Calling ID Calling ID
With Calling ID not Host Calling ID Calling ID not Host Calling ID Host Calling ID
MSISDN sent sent
filter set
to F31
1. Calling Station ID in RADIUS (attribute 31) in authentication for proxy services or calling number AVP (22) for L2TP tunnel
services.
2. Only for proxy services.
3. Service profile is not set to filter MSISDN.
You can use the show ssg connection command to display the attributes that are being filtered.
DNS Server Address
(Optional) Specifies the primary and/or secondary DNS servers for this service.

78-17497-01 335
If two servers are specified, SSG can send DNS requests to the primary DNS server until performance
is diminished or it fails (failover).
Service-Info = "Dip_address_1[;ip_address_2]"
Syntax Description
ip_address_1 IP address of the primary DNS server.

ip_address_2 (Optional) IP address of the secondary DNS server used for fault tolerance.
Example
Service-Info = "D192.168.1.2;192.168.1.3"
Domain Name
(Optional) Specifies domain names that get DNS resolution from the DNS servers specified by the DNS
server address.
Service-Info = “Oname1[;name2]...[;nameX]”
Syntax Description
name1 Domain name that gets DNS resolution from this server.
name2...X (Optional) Additional domain names that get DNS resolution from this
server.
Usage
Use the DNS Resolution attribute to specify domain names that get DNS resolution from this DNS
server.
Example
Service-Info = "Ocisco.com;cisco-sales.com"
Note Multiple instances of the Domain Name attribute can occur within a single service profile.
Full Username
Indicates that RADIUS authentication and accounting requests use the full username (user@service).
This attribute is supported by SSG with SSD or SESM in RADIUS mode.
Service-Info = “X”
The size of the full username is limited to the smaller of the following values:
• 246 bytes (10 bytes less than the standard RADIUS protocol limitation)
• 10 bytes less than the maximum size of the RADIUS attribute supported by your proxy

Service-Info = "X"

9,251 = "X"

336 78-17497-01
MTU Size
Specifies the PPP MTU size of SSG as a LAC. By default, the PPP MTU size is 1500 bytes.
Service-Info = "Bsize"
Note SESM in LDAP mode does not support the use of this attribute.
Syntax Description
size MTU size in bytes

9,251 = "B1500"

9,1 = "B1500"
RADIUS Server
(Required for proxy services.) Specifies the remote RADIUS servers that SSG uses to authenticate,
authorize, and perform accounting for a service logon for a proxy service type. This attribute is only used
in proxy service profiles and is required.
You can configure each remote RADIUS server with timeout and retransmission parameters. SSG will
perform failover among the servers.
Service-Info =
“SRadius-server-address;auth-port;acct-port;secret-key[;retrans;timeout;deadtime]”
Syntax Description
RADIUS-server-addres IP address of the RADIUS server.

s
auth-port UDP port number for authentication and authorization requests.
acct-port UDP port number for accounting requests.
secret-key Secret key shared with RADIUS clients.
retrans Number of retransmissions. Default is 3.
timeout Time, in seconds, before retransmission. Default is 5.
deadtime Time, in minutes, during which SSG does not try to perform authentication
or accounting with a AAA server that was detected as down. Default is 10.
Example
Service-Info = "S192.168.1.1;1645;1646;cisco"
Service Authentication Type
Specifies whether SSG uses the CHAP or PAP protocol to authenticate users for proxy services.

78-17497-01 337
Service-Info = "Aauthen-type"
Syntax Description
authen-type C—CHAP Authentication.

P—PAP Authentication.
Example
Service-Info = "AC"
Service-Defined Cookie
Enables you to include user-defined information in RADIUS authentication and accounting requests.
This attribute is supported by SSG with SSD or SESM in RADIUS mode.
Service-Info = “Vstring”
Syntax Description
string Information that you choose 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:
• 10 bytes less than the maximum size of the RADIUS attribute supported by
your proxy

Service-Info = "VserviceIDandAAA-ID"

9,251 = "VserviceIDandAAA-ID"
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.
• SSG supports only one Service-Defined Cookie per RADIUS service profile.
Service Description
(Optional) Describes the service.

Service-Info = “Idescription”
Syntax Description
description Description of the service.

338 78-17497-01
Example
Service-Info = "ICompany Intranet Access"
Service Mode
(Optional) Defines whether the user is able to log on to this service while simultaneously connected to
other services (concurrent mode) or whether the user cannot access any other services while using this
service (sequential mode). The default is concurrent mode.
Service-Info = “Mmode”
Syntax Description
mode S—Sequential mode.

C—Concurrent mode. This is the default.
Example
Service-Info = "MS"
Service Next-Hop Gateway
(Optional) Specifies the next-hop key for this service. Each SSG uses its own next-hop gateway table to
associate this key with an actual IP address.
Service-Info = “Gkey”
Syntax Description
key Name of the next hop.
Example
Service-Info = "Gnexthop1"
Service Route
Specifies networks available to the user for this service.

Service-Info = “Rip_address;mask”
Syntax Description
ip_address IP address.
mask Subnet mask.
Usage
Use the Service Route attribute to specify networks that exist for a service.

78-17497-01 339
Note An Internet service is typically specified as "R0.0.0.0;0.0.0.0" in the service profile.
Example
Service-Info = "R192.168.1.128;255.255.255.192"
Note There can be multiple instances of the Service Route attribute within a single service profile.
Service URL
(Optional) Specifies the URL that is displayed in the SESM HTTP address field when the service opens.
Service-Info = “Hurl”
or
Service-Info = “Uurl”
If the SESM web application is designed to use HTML frames, 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:
• Hurl—URL for a service displayed in a frame in the SESM browser window.
• Uurl—URL for a service displayed in its own browser window.
Note In a frameless application, both H and U cause a new browser window to open for the service. The
NWSP application is a frameless application.
Example
Service-Info = "Uhttp://www.fictiousname.com"
Type of Service
(Optional) Indicates whether the service is proxy, tunnel, or passthrough.

Service-Info = “Ttype”
Syntax Description
type P—Pass-through. Indicates that the user’s packets are forwarded through
the SSG. This is the default.
T—Tunnel. Indicates that this is a tunneled service.
X—Proxy. Indicates that the SSG performs proxy service.

Service-Info = "TT"

9,251 = "TT"

340 78-17497-01
Service Group Profiles

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 36 describes attributes that can be used in SSG service-group profiles.
Table 36 Service-Group Profile Attributes
Account-Info Attributes
Group Description Provides a description of the service group.
Service Group (Reply attribute) Lists services that belong to the service group.
Multiple instances of this attribute can occur within a single user profile.
Use one attribute for each service.
Service Name Lists the service subgroups that belong to the service group. When
configured, the service-group and service-name attributes can define an
organized directory structure for accessing services.
There can be multiple instances of this attribute within a service-group
profile. Use one attribute for each service subgroup that belongs to this
service group.
Standard Attributes1
Password (Check attribute) Specifies the password.
Service-Type (Check attribute) Specifies the level of service. Must be “outbound.”
1. Standard attributes are described in detail in RFC 2138.
Group Description
Describes the service group to SESM. If this attribute is omitted, the service group profile name is used.
Account-Info = "Idescription"
Syntax Description
description Description of the service group.
Example
Account-Info = "ICompany Intranet Access"
Service Group
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.
Account-Info = "Gname"

78-17497-01 341
Syntax Description
name Name of the group profile.
Example
Account-Info = "GServiceGroup1"
Note Multiple instances of the Service Group attribute can occur within a user or service-group
profile. Use one attribute for each service subgroup.
Service Name
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.
Account-Info = "Nname"
Syntax Description
name Name of the service profile.
Example
Account-Info = "Ncisco.com"
Note Multiple instances of the Service Name attribute can occur within a user or service profile. Use
one attribute for each service.
Pseudo-Service Profiles
Pseudo-service profiles 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 Filter Pseudo-Service Profile
Transparent pass-through is designed to allow unauthenticated traffic (users or network devices that have
not logged in to the SSG through SESM) to be routed through normal Cisco IOS processing.
Table 37 lists the Cisco AVPair attributes that appear within transparent pass-through filter
pseudo-service profiles. The Cisco-AVpair attributes are used to configure ACLs.
Table 37 Transparent Pass-Through Filter Pseudo-Service Profile Attributes
Downstream Access Control List Specifies either a Cisco IOS standard access control list or an
(outacl) 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
(inacl) extended access control list to be applied to upstream traffic
coming from the user.

342 78-17497-01

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.
Syntax Description

Example

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.
Syntax Description

Example
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.

78-17497-01 343
You can also create ACLs locally.
Next-Hop Gateway Pseudo-Service Profile
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 38 describes the attribute that can be used in Next-Hop Gateway
pseudo-service profiles.
Table 38 Next-Hop Gateway Pseudo-Service Profile Attributes
Attribute Usage
Next-Hop Gateway Table Entry Associates next-hop gateway keys with IP addresses.
Next-Hop Gateway Table Entry

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.
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.
Control-Info = "Gkey;ip_address "
Syntax Description
key Service name or key specified in the Next-Hop Gateway service profile.
ip_address IP address of the next hop for this service.
Usage
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.
Example
Control-Info = "GNHT_for_SSG_1;192.168.1.128"
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.

344 78-17497-01
Examples of SSG RADIUS Profiles
Subscriber Profile: Examples
The following is an example of a user profile. The profile is formatted for use with a freeware RADIUS
server:
bert Password = "ernie"
Session-Timeout = 21600,
Account-Info = "GServiceGroup1",
Account-Info = "Nservice1.com",
Account-Info = "Ngamers.net"
The following is the same profile as above, formatted for CiscoSecure ACS for UNIX:
user = bert {
radius = SSG {
check_items = {
2 = "ernie"
}
reply_attributes = {
27 = 21600
9,250 = "GServiceGroup1”
9,250 = "Nservice1.com"
9,250 = "Ngamers.net"
Service Profile: Examples
Service Profile Formatted for use with a Freeware RADIUS Server: Example
The following is a service profile formatted for use with a freeware RADIUS server:
service1.com Password = "cisco", Service-Type = outbound,
Idle-Timeout = 1800,
Service-Info = "R192.168.1.128;255.255.255.192",
Service-Info = "R192.168.2.0;255.255.255.192",
Service-Info = "R192.168.3.0;255.255.255.0",
Service-Info = "Gservice1",
Service-Info = "D192.168.2.81",
Service-Info = "MC",
Service-Info = "TP",
Service-Info = "ICompany Intranet Access",
Service-Info = "Oservice1.com"
Service Profile Formatted for use with a Freeware RADIUS Server Formatted for CiscoSecure ACS for UNIX:
Example
user = service1.com {
radius = SSG {
check_items = {
2 = "cisco"
6 = 5
}
28 = 1800
9,251 = "R192.168.1.128;255.255.255.192"
9,251 = "R192.168.2.0;255.255.255.192"
9,251 = "R192.168.3.0;255.255.255.0"
9,251 = "Gservice1"

78-17497-01 345
9,251 = "D192.168.2.81"
9,251 = "MC"
9,251 = "TP"
9,251 = "ICompany Intranet Access"
9,251 = “Oservice1.com”
}
RADIUS ProxyService Profile: Example

The following is an example of a proxy RADIUS service profile. This profile contains the
Service-Defined Cookie attribute and a Full Username attribute.
user = serv1-proxy{
profile_id = 98
profile_cycle = 42
member = Single_Logon
radius=6510-SSG-v1.1a {
check_items= {
2=alex
}
reply_attributes= {
9,251="Oservice1.com"
9,251="R10.13.0.0;255.255.0.0"
9,251="TX"
9,251="D10.13.1.5"
9,251="S10.13.1.2;1645;1646;my-secret"
9,251="Gmy-key"
9,251="X"
9,251="Vproxy-service_at_X.X.X.X"
}
Service Group Profile: Examples
Service Group Profile Formatted for use with a Freeware RADIUS Server: Example
The following is an example of a service group profile. The profile is formatted for use with a freeware
RADIUS server:
ServiceGroup1 Password = "cisco", Service-Type = outbound,
Account-Info = "Nservice1.com",
Account-Info = "Ngamers.net",
Account-Info = "IStandard User Services"
Service Group Profile Formatted for use with a Freeware RADIUS Server Formatted for CiscoSecure ACS for UNIX:
Example
The following is the same service-group profile, formatted for CiscoSecure ACS for UNIX:
user = ServiceGroup1 {
radius = SSG {
check_items = {
2 = "cisco"
6 = 5
9,250 = "Nservice1.com"
9,250 = "Ngamers.net"
9,250 = "GServiceGroup3"
9,250 = "GServiceGroup4"

346 78-17497-01
9,250 = "IStandard User Services"

}
Pseudo-Service Profile: Examples
Transparent Pass-Through Filter Pseudo-Service Profile: Example

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:
ssg-filter Password = "cisco", Service-Type = outbound,
Cisco-AVpair="ip:inacl#3=deny tcp 192.168.1.0 0.0.0.255 any eq 21",
Cisco-AVpair="ip:inacl#7=permit ip any any"
user = ssg-filter {
radius = SSG {
check_items = {
2 = "cisco"
6 = 5
9,1 = "ip:inacl#3=deny tcp 192.168.1.0 0.0.0.255 any eq 21",
9,1 = "ip:inacl#7=permit ip any any"
}
}
}
Next-Hop Gateway Pseudo-Service Profile Example

The following is an example of the Next-Hop Gateway pseudo-service profile. The profile is formatted
for use with a freeware RADIUS server:
nht1 Password = "cisco", Service-Type = outbound,
Account-Info = "Gservice3;192.168.103.3",
Account-Info = "GLabservices;192.168.4.2",
Account-Info = "GWorldwide_Gaming;192.168.4.2"
The following is the same Next-Hop Gateway pseudo-service profile, formatted for CiscoSecure ACS
for UNIX:
user = nht1{
radius= SSG {
check_items= {
2=cisco
6=5
}
reply_attributes= {
9,253="Gservice3;192.168.103.3"
9,253="Gservice2;192.168.103.2"
9,253="Gservice1;192.168.103.1"
9,253="GLabservices;192.168.4.2"
9,253="GWorldwide_Gaming;192.168.4.2"
}
}

78-17497-01 347
RADIUS Accounting Records for SSG

• Account Logon, page 348
• Account Logoff, page 348
• Connection Start, page 349
• Connection Stop, page 350
• Attributes Used in Accounting Records, page 352
Note This section applies if you are using SSG with SSD or 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.
Account Logon
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:
NAS-IP-Address = ip_address
User-Name = "username"
Acct-Session-Id = "session_id"
Framed-IP-Address = user_ip
Proxy-State = "n"
Table 39 describes the attributes shown in the display.
Table 39 Account Logon Accounting Record Attributes
Acct-Status-Type Indicates whether this Accounting-Request marks the beginning of
the user service (start) or the end (stop).
NAS-IP-Address IP address of SSG.
User-Name Name used to log on to the service provider network.
Acct-Session-Id Session number.
Framed-IP-Address IP address of the user’s system.
Proxy-State Accounting record queuing information (has no effect on account
billing).
Account Logoff
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:
NAS-IP-Address = ip_address

348 78-17497-01
Acct-Session-Time = time
Acct-Terminate-Cause = cause
Acct-Session-Id = "session_id"
Framed-IP-Address = user_ip
Proxy-State = "n"
Table 40 Account Logoff Accounting Record Attributes
Acct-Session-Time Length of session, in seconds.
Acct-Terminate-Cause Cause of account termination:
• User-Request
• Session-Timeout
• Idle-Timeout
• Lost-Carrier
Proxy-State Accounting record queuing information (has no effect on account
billing).
Connection Start
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:
NAS-Port = 0
Service-Info = "Nisp-name.com"
Service-Info = "Uusername"
Service-Info = "TP"
Acct-Delay-Time = 0

78-17497-01 349
Table 41 Connection Start Accounting Record Attributes
NAS-Port Physical port number of the network access server that is
authenticating the user.
NAS-Port-Type Type of physical port that the network access server is using to
authenticate the user.
Acct-Authentic Indicates how the user was authenticated, whether by RADIUS, the
network access server itself, or another remote authentication
protocol.
Service-Type Indicates the type of service requested or the type of service to be
provided. PPP and SLIP connections use the service type “Framed”.
Framed-Protocol Indicates the framing to be used for framed access.
Service-Info “Nname”. Name of the service profile.
Service-Info “Uname”. Username used to authenticate the user with the remote
RADIUS server. This attribute is used for proxy services.
Service-Info “Ttype”. Indicates whether the connection is proxy, tunnel, or
pass-through.
• P—Pass-through (usually the Internet)
• T—Tunnel
• X—Proxy
Acct-Delay-Time Indicates for how many seconds the client has been trying to send a
particular record.
Connection Stop
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:
NAS-Port = 0
User-Name = "zeus"
Service-Type = Framed-User
Acct-Input-Octets = 0
Acct-Output-Octets = 649
Acct-Input-Packets = 0
Acct-Output-Packets = 17

350 78-17497-01
Framed-IP-Address = 201.168.101.10
Control-Info = "I0;0"
Control-Info = "O0;649"
Service-Info = "Ninternet"
Service-Info = "Uzeus"
Service-Info = "TP"
Acct-Delay-Time = 0
Table 42 Connection Stop Accounting Record Attributes
authenticating the user.
authenticate the user.
Service-Type Indicates the type of service requested or the type of service to be
provided. PPP and SLIP connections use the service type “Framed”.
Acct-Terminate-Cause Cause of service termination:
• User-Request
• Lost-Carrier
• Lost-Service
• Session-Timeout
• Idle-Timeout
Acct-Session-Time Indicates for how long, in seconds, the user has been receiving
service.
Acct-Input-Octets Number of octets that have been received from the port over the
course of providing a service.
Acct-Output-Octets Number of octets that have been sent to the port in the course of
delivering a service.
Acct-Input-Packets Number of octets that have been received from the port over the
course of providing a service to a framed user.
Acct-Output-Packets Number of octets that have been sent to the port in the course of
delivering a service to a framed user.
Framed-Protocol Indicates the framing to be used for framed access.
Control-Info “Irollover;value”. Number of times the 32-bit integer rolls over and
the value of the integer when it overflows for inbound data.

78-17497-01 351
Table 42 Connection Stop Accounting Record Attributes (continued)
Control-Info “Orollover;value”. Number of times the 32-bit integer rolls over
and the value of the integer when it overflows for outbound data.
Service-Info “Nname”. Name of the service profile.
Service-Info “Uname”. Username used to authenticate the user with the remote
RADIUS server. This attribute is used for proxy services.
Service-Info “Ttype”. Indicates whether the connection is proxy, tunnel, or
pass-through.
• P—Pass-through (usually the Internet)
• T—Tunnel
• X—Proxy
Acct-Delay-Time Indicates for how many seconds the client has been trying to send a
particular record.
Attributes Used in Accounting Records

The following attributes are used for accounting purposes only. They do not appear in profiles.
Service User
The Service User attribute provides the username used by the SESM user to log on to the service and
presented for authentication with the home gateway.
Service-Info = "Uusername"
Syntax Description
username The name provided by the user for authentication.
Example
Service-Info = "Ujoe@cisco.com"
Note The Service User attribute is used only for accounting purposes and does not appear in profiles.
Service Name
The Service Name attribute defines the name of the service.

Service-Info = "Nname"
Syntax Description
name Name of the service profile or service that belongs to a service group.
Example
Service-Info = "Nservice1.com"

352 78-17497-01
Note The Service Name attribute is used only for accounting purposes and does not appear in profiles.
Octets Output
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.
Control-Info = "Orollover;value"
Syntax Description
rollover Number of times the 32-bit integer rolls over to 0.

value Value in the 32-bit integer when the stop record is generated and the service
or user is logged out.
Usage
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:
rollover * 232 + value
Example
In the following example, rollover is 2 and value is 153 (2 * 232 + 153 = 8589934745):
Control-Info = "O2;153"
Note The Octets Output attribute is used only for accounting purposes and does not appear in profiles.
Octets Input
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.
Control-Info = "Irollover;value"
Syntax Description
rollover Number of times the 32-bit integer rolls over to 0.

value Value in the 32-bit integer when the stop record is generated and the service
or user is logged out.

78-17497-01 353
Usage
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:
rollover * 232 + value
Example
In the following example, rollover is 3 and value is 151 (3 * 232 + 151 = 12884902039):
Control-Info = "I3;151"
Note The Octets Input attribute is used only for accounting purposes and does not appear in profiles.
Class Attribute
The class attribute is an arbitrary value that the network access server includes in all accounting packets
for this user if supplied by the RADIUS server.
Full Username RADIUS
The Full Username RADIUS attribute allows SSG to include the user’s full username and domain
(user@service) in the RADIUS authentication and accounting requests.
Restrictions for SSG Full Username RADIUS Attribute

The size of the full username is limited to the smaller of the following values:
• 10 bytes less than the maximum size of the RADIUS attribute supported by your proxy
Configuration Examples for SSG Full Username RADIUS Attribute

RADIUS Freeware Format: Example
Service-Info = “X”

9,251 = “X”
Acct-Session Id
A unique accounting identifier that makes it easy to match start and stop records in a log file.
Acct-session ID numbers restart at 1 each time the router is power cycled or the software is reloaded.
3GPP VSAs in Accounting Records
When a RADIUS client (GGSN) sends the 3GPP attributes (IMSI, ChargingID and SGSN address) in
sending Access Request Packet, SSG caches these attributes in this host’s proxy logon attributes. When
accounting records (start/interim/stop) are sent for this user (host/service accounting records) these
3GPP attributes will be sent.
Format of these attributes:

3GPP Vendor Id = 10415

354 78-17497-01
Octets8 7 6 5 4 3 2 1
1 Type = 26
2 Length = n
3 Vendor id octet 1
4 Vendor id octet 2
5 Vendor id octet 3
6 Vendor id octet 4
7-n String
where n> = 7
These attributes must also be included, if available, in authorization requests (that is for pre-paid
authorization) and remote authentication requests (authentication of the user at a remote AAA sever for
proxy service).
NAS-Port in Authentications
When a user accesses a service, SSG sends a RADIUS Accounting-Request to the accounting server. The
RADIUS Accounting-Request record contains attributes to define the Network Access Server. The
NAS-Port attributes are described in Table 43.

78-17497-01 355
Table 43 NAS-Port Accounting Record Attributes
authenticating the user. The NAS-Port value (32 bits) consists of
one or two 16-bit values (depending on the setting of the
radius-server extended-portnames command. Each 16-bit
number should be viewed as a 5-digit decimal integer for
interpretation as follows:
• For asynchronous terminal lines, async network interfaces, and
virtual async interfaces, the value is 00ttt where ttt is the line
number or async interface unit number.
• For ordinary synchronous network interface, the value is
10xxx.
• For channels on a primary rate ISDN interface, the value is
2ppcc.
• For channels on a basic rate ISDN interface, the value is 3bb0c.
• For other types of interfaces, the value is 6nnss.
authenticate the user. Physical ports are indicated by a numeric
value as follows:
0: Asynchronous
1: Synchronous
2: ISDN-Synchronous
3: ISDN-Asynchronous (V.120)
4:ISDN-Asynchronous (V.110)
5: Virtual
The following sections provide references related to RADIUS Profiles and Attributes for SSG.

356 78-17497-01
Feature Information for RADIUS Profiles and Attributes for SSG
Related Documents
Release 12.4
Description Link
even more content.

features that were introduced or modified in Cisco IOS Release 12.0(3)DC or a later release appear in
the table.

78-17497-01 357
Table 44 Feature Information for RADIUS Profiles and Attributes for SSG

RADIUS Profiles and Attributes for SSG 12.0(3)DC SSG uses RADIUS Profiles and attributes for the
12.2(4)B authentication, authorization, and accounting of
12.2(11)T subscribers.
12.3(4)T feature:
12.3(7)T
12.3(14)T • RADIUS Profiles for SSG Support, page 301
12.4 • SSG Vendor-Specific Attributes, page 302
• Subscriber Profiles, page 329
• Service Profiles, page 332
• Service Group Profiles, page 341
• Pseudo-Service Profiles, page 342
• Examples of SSG RADIUS Profiles, page 345
• RADIUS Accounting Records for SSG, page 348
• Attributes Used in Accounting Records, page 352

358 78-17497-01

Cisco IOS Service Selection Gateway Configuration Guide, Release 12.4

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco IOS Service Selection Gateway Configuration Guide, Release 12.4

Uploaded by

Copyright:

Available Formats

Cisco IOS Service Selection Gateway

Customer Order Number: DOC-7817497=

Cisco IOS Service Selection Gateway Configuration Guide

About Cisco IOS Software Documentation for Release 12.4 xix

Documentation Objectives xix

Documentation Organization for Cisco IOS Release 12.4 xx

Document Conventions xxvi

Obtaining Documentation xxvii

Cisco Product Security Overview xxix

Obtaining Technical Assistance xxx

Using Cisco IOS Software for Release 12.4 xxxiii

Understanding Command Modes xxxiii

Getting Help xxxiv

Using the no and default Forms of Commands xxxviii

Saving Configuration Changes xxxviii

Filtering Output from the show and more Commands xxxix

Finding Additional Feature Support Information xxxix

Service Selection Gateway Features Roadmap 1

Prerequisites for SSG 7

Restrictions for SSG 7

Information About SSG 8

Cisco IOS Service Selection Gateway Configuration Guide

Overview of Cisco’s Subscriber Edge Services Solution 8

Implementing SSG: Initial Tasks 17

Prerequisites for Implementing SSG 17

Restrictions for Implementing SSG 18

How to Establish Initial SSG Communication 18

Cisco IOS Service Selection Gateway Configuration Guide

Benefits of SSG Port-Bundle Host-Key 29

Configuring SSG to Serve as a RADIUS Proxy 43

Prerequisites for SSG RADIUS Proxy 43

Restrictions for SSG RADIUS Proxy 44

Cisco IOS Service Selection Gateway Configuration Guide

Configuring SSG RADIUS Proxy for GPRS Networks 53

Cisco IOS Service Selection Gateway Configuration Guide

SSG RADIUS Proxy for 802.1x WLAN Deployments: Example 76

Configuring SSG to Authenticate Web Logon Subscribers 81

Prerequisites for Configuring SSG to Authenticate Web Logon Subscribers 81

Restrictions for Configuring SSG to Authenticate Web Logon Subscribers 82

Information About Web Logon Subscribers 82

Configuration Examples for SSG Authentication for Web Logon Subscribers 87

Configuring SSG to Authenticate PPP Subscribers 91

Information About SSG Authentication of PPP Subscribers 92

Cisco IOS Service Selection Gateway Configuration Guide

Configuring a PTA-MD Exclusion List 95

Configuration Examples for SSG Authentication of PPP Subscribers 98

Additional References 102

Configuring SSG to Authenticate Subscribers with Transparent Autologon 105

Prerequisites for SSG Transparent Autologon 105

Restrictions for SSG Transparent Autologon 106

Information About SSG Transparent Autologon 106

Cisco IOS Service Selection Gateway Configuration Guide

Configuration Examples for SSG Transparent Autologon 117

Additional References 118

Configuring SSG to Authenticate Subscribers Automatically in the Service Domain 121

Prerequisites for SSG AutoDomain 121

Restrictions for SSG AutoDomain 122

Information About SSG AutoDomain 122

Additional References 131

Cisco IOS Service Selection Gateway Configuration Guide

Configuring SSG for On-Demand IP Address Renewal 135

Prerequisites for SSG On-Demand IP Address Renewal 135

Restrictions for SSG On-Demand IP Address Renewal 136