Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download PDF - Complete Book (3.78 MB)
Document related concepts
no text concepts found
Transcript
Cisco IOS Service Selection Gateway
Configuration Guide
Release 12.4T
Americas 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 527-0883
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.
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, the Cisco logo, DCE, and Welcome to the Human Network are
trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You,
Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems,
Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing,
FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo,
LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels,
ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the
WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship
between Cisco and any other company. (0807R)
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
© 2008 Cisco Systems, Inc. All rights reserved.
About Cisco IOS and Cisco IOS XE Software
Documentation
Last updated: August 6, 2008
This document describes the objectives, audience, conventions, and organization used in Cisco IOS and
Cisco IOS XE software documentation, collectively referred to in this document as Cisco IOS
documentation. Also included are resources for obtaining technical assistance, additional
documentation, and other information from Cisco. This document is organized into the following
sections:
•
Documentation Objectives, page i
•
Audience, page i
•
Documentation Conventions, page ii
•
Documentation Organization, page iii
•
Additional Resources and Documentation Feedback, page xi
Documentation Objectives
Cisco IOS documentation describes the tasks and commands available to configure and maintain Cisco
networking devices.
Audience
The Cisco IOS documentation set is i ntended 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 commands necessary to perform
particular tasks. The Cisco IOS documentation set is also intended for those users experienced with
Cisco IOS who need to know about new features, new configuration options, and new software
characteristics in the current Cisco IOS release.
i
About Cisco IOS and Cisco IOS XE Software Documentation
Documentation Conventions
Documentation Conventions
In Cisco IOS documentation, the term router may be used to refer to various Cisco products; for example,
routers, access servers, and switches. These and other networking devices that support Cisco IOS
software are shown interchangeably in examples and are used only for illustrative purposes. An example
that shows one product does not necessarily mean that other products are not supported.
This section includes the following topics:
•
Typographic Conventions, page ii
•
Command Syntax Conventions, page ii
•
Software Conventions, page iii
•
Reader Alert Conventions, page iii
Typographic Conventions
Cisco IOS documentation uses the following typographic conventions:
Convention
Description
^ or Ctrl
Both the ^ symbol and Ctrl represent the Control (Ctrl) key on a keyboard. For
example, the key combination ^D or Ctrl-D means that you 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 a Simple Network Management Protocol (SNMP) community string to
public, do not use quotation marks around the string; otherwise, the string will
include the quotation marks.
Command Syntax Conventions
Cisco IOS documentation uses the following command syntax conventions:
ii
Convention
Description
bold
Bold text indicates commands and keywords that you enter as shown.
italic
Italic text indicates arguments for which you supply values.
[x]
Square brackets enclose an optional keyword or argument.
|
A vertical line, called a pipe, indicates a choice within a set of keywords
or arguments.
[x | y]
Square brackets enclosing keywords or arguments separated by a pipe indicate an
optional choice.
{x | y}
Braces enclosing keywords or arguments separated by a pipe indicate a
required choice.
[x {y | z}]
Braces and a pipe within square brackets indicate a required choice within an
optional element.
About Cisco IOS and Cisco IOS XE Software Documentation
Documentation Organization
Software Conventions
Cisco IOS uses the following program code conventions:
Convention
Description
Courier font
Courier font is used for information that is displayed on a PC or terminal screen.
Bold Courier font
Bold Courier font indicates text that the user must enter.
<
>
!
[
Angle brackets enclose text that is not displayed, such as a password. Angle
brackets also are used in contexts in which the italic font style is not supported;
for example, ASCII text.
An exclamation point at the beginning of a line indicates that the text that follows
is a comment, not a line of code. An exclamation point is also displayed by
Cisco IOS software for certain processes.
]
Square brackets enclose default responses to system prompts.
Reader Alert Conventions
The Cisco IOS documentation set uses the following conventions for reader alerts:
Caution
Note
Timesaver
Means reader be careful. In this situation, you might do something that could result in equipment
damage or loss of data.
Means reader take note. Notes contain helpful suggestions or references to material not covered in the
manual.
Means the described action saves time. You can save time by performing the action described in the
paragraph.
Documentation Organization
This section describes the Cisco IOS documentation set, how it is organized, and how to access it on
Cisco.com. Included are lists of configuration guides, command references, and supplementary
references and resources that make up the documentation set. The following topics are included:
•
Cisco IOS Documentation Set, page iv
•
Cisco IOS Documentation on Cisco.com, page iv
•
Configuration Guides, Command References, and Supplementary Resources, page v
iii
About Cisco IOS and Cisco IOS XE Software Documentation
Documentation Organization
Cisco IOS Documentation Set
Cisco IOS documentation consists of the following:
•
Release notes and caveats provide information about platform, technology, and feature support for
a release and describe severity 1 (catastrophic), severity 2 (severe), and severity 3 (moderate) defects
in released Cisco IOS code. Review release notes before other documents to learn whether or not
updates have been made to a feature.
•
Sets of configuration guides and command references organized by technology and published for
each standard Cisco IOS release.
– Configuration guides—Compilations of documents that provide informational and
task-oriented descriptions of Cisco IOS features.
– Command references—Compilations of command pages that provide detailed information
about the commands used in the Cisco IOS features and processes that make up the related
configuration guides. For each technology, there is a single command reference that covers all
Cisco IOS releases and that is updated at each standard release.
•
Lists of all the commands in a specific release and all commands that are new, modified, removed,
or replaced in the release.
•
Command reference book for debug commands. Command pages are listed in alphabetical order.
•
Reference book for system messages for all Cisco IOS releases.
Cisco IOS Documentation on Cisco.com
The following sections describe the documentation organization and how to access various document
types.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS
software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An
account on Cisco.com is not required.
New Features List
The New Features List for each release provides a list of all features in the release with hyperlinks to the
feature guides in which they are documented.
Feature Guides
Cisco IOS features are documented in feature guides. Feature guides describe one feature or a group of
related features that are supported on many different software releases and platforms. Your Cisco IOS
software release or platform may not support all the features documented in a feature guide. See the
Feature Information table at the end of the feature guide for information about which features in that
guide are supported in your software release.
Configuration Guides
Configuration guides are provided by technology and release and comprise a set of individual feature
guides relevant to the release and technology.
iv
About Cisco IOS and Cisco IOS XE Software Documentation
Documentation Organization
Command References
Command reference books describe Cisco IOS commands that are supported in many different software
releases and on many different platforms. The books are provided by technology. For information about
all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup
or the Cisco IOS Master Command List, All Releases, at
http://www.cisco.com/en/US/docs/ios/mcl/all_release/all_mcl.html.
Cisco IOS Supplementary Documents and Resources
Supplementary documents and resources are listed in Table 2 on page xi.
Configuration Guides, Command References, and Supplementary Resources
Table 1 lists, in alphabetical order, Cisco IOS and Cisco IOS XE software configuration guides and
command references, including brief descriptions of the contents of the documents. The Cisco IOS
command references are comprehensive, meaning that they include commands for both Cisco IOS
software and Cisco IOS XE software, for all releases. The configuration guides and command references
support many different software releases and platforms. Your Cisco IOS software release or platform
may not support all these technologies.
For additional information about configuring and operating specific networking devices, go to the
Product Support area of Cisco.com at http://www.cisco.com/web/psa/products/index.html.
Table 2 lists documents and resources that supplement the Cisco IOS software configuration guides and
command references. These supplementary resources include release notes and caveats; master
command lists; new, modified, removed, and replaced command lists; system messages; and the debug
command reference.
Table 1
Cisco IOS and Cisco IOS XE Configuration Guides and Command References
Configuration Guide and Command Reference Titles
Features/Protocols/Technologies
Cisco IOS AppleTalk Configuration Guide
AppleTalk protocol.
Cisco IOS XE AppleTalk Configuration Guide
Cisco IOS AppleTalk Command Reference
Cisco IOS Asynchronous Transfer Mode
Configuration Guide
LAN ATM, multiprotocol over ATM (MPoA), and WAN ATM.
Cisco IOS Asynchronous Transfer Mode
Command Reference
v
About Cisco IOS and Cisco IOS XE Software Documentation
Documentation Organization
Table 1
Cisco IOS and Cisco IOS XE Configuration Guides and Command References (continued)
Configuration Guide and Command Reference Titles
Cisco IOS Bridging and IBM Networking
Configuration Guide
Features/Protocols/Technologies
•
Transparent and source-route transparent (SRT) bridging,
source-route bridging (SRB), Token Ring Inter-Switch Link
(TRISL), and token ring route switch module (TRRSM).
•
Data-link switching plus (DLSw+), serial tunnel (STUN),
block serial tunnel (BSTUN); logical link control, type 2
(LLC2), synchronous data link control (SDLC); IBM
Network Media Translation, including Synchronous Data
Logical Link Control (SDLLC) and qualified LLC (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.
Cisco IOS Bridging Command Reference
Cisco IOS IBM Networking Command Reference
Cisco IOS Broadband and DSL Configuration Guide
Cisco IOS XE Broadband and DSL Configuration Guide
Point-to-Point Protocol (PPP) over ATM (PPPoA) and PPP over
Ethernet (PPPoE).
Cisco IOS Broadband and DSL Command Reference
Cisco IOS Carrier Ethernet Configuration Guide
Cisco IOS Carrier Ethernet Command Reference
Cisco IOS Configuration Fundamentals
Configuration Guide
Cisco IOS XE Configuration Fundamentals
Configuration Guide
Connectivity fault management (CFM), Ethernet Local
Management Interface (ELMI), IEEE 802.3ad link bundling,
Link Layer Discovery Protocol (LLDP), media endpoint
discovery (MED), and operations, administration, and
maintenance (OAM).
Autoinstall, Setup, Cisco IOS command-line interface (CLI),
Cisco IOS file system (IFS), Cisco IOS web browser user
interface (UI), basic file transfer services, and file management.
Cisco IOS Configuration Fundamentals
Command Reference
Cisco IOS DECnet Configuration Guide
DECnet protocol.
Cisco IOS XE DECnet Configuration Guide
Cisco IOS DECnet Command Reference
Cisco IOS Dial Technologies Configuration Guide
Cisco IOS XE Dial Technologies Configuration Guide
Cisco IOS Dial Technologies Command Reference
Cisco IOS Flexible NetFlow Configuration Guide
Cisco IOS Flexible NetFlow Command Reference
vi
Asynchronous communications, dial backup, dialer technology,
dial-in terminal services and AppleTalk remote access (ARA),
large scale dialout, dial-on-demand routing, dialout, modem and
resource pooling, ISDN, multilink PPP (MLP), PPP, virtual
private dialup network (VPDN).
Flexible NetFlow.
About Cisco IOS and Cisco IOS XE Software Documentation
Documentation Organization
Table 1
Cisco IOS and Cisco IOS XE Configuration Guides and Command References (continued)
Configuration Guide and Command Reference Titles
Features/Protocols/Technologies
Cisco IOS H.323 Configuration Guide
Gatekeeper enhancements for managed voice services,
Gatekeeper Transaction Message Protocol, gateway codec order
preservation and shutdown control, H.323 dual tone
multifrequency relay, H.323 version 2 enhancements, Network
Address Translation (NAT) support of H.323 v2 Registration,
Admission, and Status (RAS) protocol, tokenless call
authorization, and VoIP gateway trunk and
carrier-based routing.
Cisco IOS High Availability Configuration Guide
A variety of High Availability (HA) features and technologies
that are available for different network segments (from
enterprise access to service provider core) to facilitate creation
of end-to-end highly available networks. Cisco IOS HA features
and technologies can be categorized in three key areas:
system-level resiliency, network-level resiliency, and embedded
management for resiliency.
Cisco IOS XE High Availability Configuration Guide
Cisco IOS High Availability Command Reference
Cisco IOS Integrated Session Border Controller
Command Reference
A VoIP-enabled device that is deployed at the edge of networks.
An SBC is a toolkit of functions, such as signaling interworking,
network hiding, security, and quality of service (QoS).
Cisco IOS Intelligent Service Gateway
Configuration Guide
Cisco IOS Intelligent Service Gateway
Command Reference
Subscriber identification, service and policy determination,
session creation, session policy enforcement, session life-cycle
management, accounting for access and service usage, session
state monitoring.
Cisco IOS Interface and Hardware Component
Configuration Guide
LAN interfaces, logical interfaces, serial interfaces, virtual
interfaces, and interface configuration.
Cisco IOS XE Interface and Hardware Component
Configuration Guide
Cisco IOS Interface and Hardware Component
Command Reference
Cisco IOS IP Addressing Services Configuration Guide
Cisco IOS XE Addressing Services Configuration Guide
Cisco IOS IP Addressing Services Command Reference
Cisco IOS IP Application Services Configuration Guide
Cisco IOS XE IP Application Services Configuration
Guide
Cisco IOS IP Application Services Command Reference
Cisco IOS IP Mobility Configuration Guide
Address Resolution Protocol (ARP), Network Address
Translation (NAT), Domain Name System (DNS), Dynamic
Host Configuration Protocol (DHCP), and Next Hop Address
Resolution Protocol (NHRP).
Enhanced Object Tracking (EOT), Gateway Load Balancing
Protocol (GLBP), Hot Standby Router Protocol (HSRP), IP
Services, Server Load Balancing (SLB), Stream Control
Transmission Protocol (SCTP), TCP, Web Cache
Communication Protocol (WCCP), User Datagram Protocol
(UDP), and Virtual Router Redundancy Protocol (VRRP).
Mobile ad hoc networks (MANet) and Cisco mobile networks.
Cisco IOS IP Mobility Command Reference
Cisco IOS IP Multicast Configuration Guide
Cisco IOS XE IP Multicast Configuration Guide
Cisco IOS IP Multicast Command Reference
Protocol Independent Multicast (PIM) sparse mode (PIM-SM),
bidirectional PIM (bidir-PIM), Source Specific Multicast
(SSM), Multicast Source Discovery Protocol (MSDP), Internet
Group Management Protocol (IGMP), and Multicast VPN
(MVPN).
vii
About Cisco IOS and Cisco IOS XE Software Documentation
Documentation Organization
Table 1
Cisco IOS and Cisco IOS XE Configuration Guides and Command References (continued)
Configuration Guide and Command Reference Titles
Features/Protocols/Technologies
Cisco IOS IP Routing Protocols Configuration Guide
Cisco IOS IP Routing Protocols Command Reference
Border Gateway Protocol (BGP), multiprotocol BGP,
multiprotocol BGP extensions for IP multicast, bidirectional
forwarding detection (BFD), Enhanced Interior Gateway
Routing Protocol (EIGRP), Interior Gateway Routing Protocol
(IGRP), Intermediate System-to-Intermediate System (IS-IS),
on-demand routing (ODR), Open Shortest Path First (OSPF),
and Routing Information Protocol (RIP).
Cisco IOS IP SLAs Configuration Guide
Cisco IOS IP Service Level Agreements (IP SLAs).
Cisco IOS XE IP Routing Protocols Configuration Guide
Cisco IOS XE IP SLAs Configuration Guide
Cisco IOS IP SLAs Command Reference
Cisco IOS IP Switching Configuration Guide
Cisco IOS XE IP Switching Configuration Guide
Cisco Express Forwarding, fast switching, and Multicast
Distributed Switching (MDS).
Cisco IOS IP Switching Command Reference
Cisco IOS IPv6 Configuration Guide
Cisco IOS XE IPv6 Configuration Guide
For IPv6 features, protocols, and technologies, go to the IPv6
“Start Here” document at the following URL:
Cisco IOS IPv6 Command Reference
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/
guide/ip6-roadmap.html
Cisco IOS ISO CLNS Configuration Guide
ISO connectionless network service (CLNS).
Cisco IOS XE ISO CLNS Configuration Guide
Cisco IOS ISO CLNS Command Reference
Cisco IOS LAN Switching Configuration Guide
Cisco IOS XE LAN Switching Configuration Guide
VLANs, Inter-Switch Link (ISL) encapsulation, IEEE 802.10
encapsulation, IEEE 802.1Q encapsulation, and multilayer
switching (MLS).
Cisco IOS LAN Switching Command Reference
Cisco IOS Mobile Wireless Gateway GPRS Support Node
Configuration Guide
Cisco IOS Mobile Wireless Gateway GPRS Support Node
Command Reference
Cisco IOS Mobile Wireless Home Agent
Configuration Guide
Cisco IOS Mobile Wireless Home Agent
Command Reference
Cisco IOS Mobile Wireless Packet Data Serving Node
Configuration Guide
Cisco IOS Mobile Wireless Packet Data Serving Node
Command Reference
Cisco IOS Mobile Wireless Radio Access Networking
Configuration Guide
Cisco IOS Mobile Wireless Radio Access Networking
Command Reference
viii
Cisco IOS Gateway GPRS Support Node (GGSN) in a
2.5-generation general packet radio service (GPRS) and
3-generation universal mobile telecommunication system (UMTS)
network.
Cisco Mobile Wireless Home Agent, an anchor point for mobile
terminals for which mobile IP or proxy mobile IP services are
provided.
Cisco Packet Data Serving Node (PDSN), a wireless gateway that
is between the mobile infrastructure and standard IP networks and
that enables packet data services in a code division multiple access
(CDMA) environment.
Cisco IOS radio access network products.
About Cisco IOS and Cisco IOS XE Software Documentation
Documentation Organization
Table 1
Cisco IOS and Cisco IOS XE Configuration Guides and Command References (continued)
Configuration Guide and Command Reference Titles
Features/Protocols/Technologies
Cisco IOS Multiprotocol Label Switching
Configuration Guide
MPLS Label Distribution Protocol (LDP), MPLS Layer 2 VPNs,
MPLS Layer 3 VPNs, MPLS Traffic Engineering (TE), and
MPLS Embedded Management (EM) and MIBs.
Cisco IOS XE Multiprotocol Label Switching
Configuration Guide
Cisco IOS Multiprotocol Label Switching
Command Reference
Cisco IOS Multi-Topology Routing Configuration Guide
Cisco IOS Multi-Topology Routing Command Reference
Cisco IOS NetFlow Configuration Guide
Cisco IOS XE NetFlow Configuration Guide
Unicast and multicast topology configurations, traffic
classification, routing protocol support, and network
management support.
Network traffic data analysis, aggregation caches, export
features.
Cisco IOS NetFlow Command Reference
Cisco IOS Network Management Configuration Guide
Basic system management; system monitoring and logging;
troubleshooting, logging, and fault management;
Cisco IOS XE Network Management Configuration Guide
Cisco Discovery Protocol; Cisco IOS Scripting with Tool
Cisco IOS Network Management Command Reference
Control Language (Tcl); Cisco networking services (CNS);
DistributedDirector; Embedded Event Manager (EEM);
Embedded Resource Manager (ERM); Embedded Syslog
Manager (ESM); HTTP; Remote Monitoring (RMON); SNMP;
and VPN Device Manager Client for Cisco IOS Software
(XSM Configuration).
Cisco IOS Novell IPX Configuration Guide
Novell Internetwork Packet Exchange (IPX) protocol.
Cisco IOS XE Novell IPX Configuration Guide
Cisco IOS Novell IPX Command Reference
Cisco IOS Optimized Edge Routing Configuration Guide
Cisco IOS Optimized Edge Routing Command Reference
Cisco IOS Quality of Service Solutions
Configuration Guide
Cisco IOS XE Quality of Service Solutions
Configuration Guide
Cisco IOS Quality of Service Solutions
Command Reference
Cisco IOS Security Configuration Guide
Cisco IOS XE Security Configuration Guide
Cisco IOS Security Command Reference
Optimized edge routing (OER) monitoring, policy
configuration, routing control, logging and reporting, and
VPN IPsec/generic routing encapsulation (GRE) tunnel
interface optimization.
Class-based weighted fair queuing (CBWFQ), custom queuing,
distributed traffic shaping (DTS), generic traffic shaping (GTS),
IP- to-ATM class of service (CoS), low latency queuing (LLQ),
modular QoS CLI (MQC), Network-Based Application
Recognition (NBAR), priority queuing, Security Device
Manager (SDM), Multilink PPP (MLPPP) for QoS, header
compression, AutoQoS, QoS features for voice, Resource
Reservation Protocol (RSVP), weighted fair queuing (WFQ),
and weighted random early detection (WRED).
Access control lists (ACLs), authentication, authorization, and
accounting (AAA), firewalls, IP security and encryption,
neighbor router authentication, network access security, network
data encryption with router authentication, public key
infrastructure (PKI), RADIUS, TACACS+, terminal access
security, and traffic filters.
ix
About Cisco IOS and Cisco IOS XE Software Documentation
Documentation Organization
Table 1
Cisco IOS and Cisco IOS XE Configuration Guides and Command References (continued)
Configuration Guide and Command Reference Titles
Features/Protocols/Technologies
Cisco IOS Service Selection Gateway Configuration Guide Subscriber authentication, service access, and accounting.
Cisco IOS Service Selection Gateway Command Reference
Cisco IOS Software Activation Configuration Guide
Cisco IOS Software Activation Command Reference
Cisco IOS Software Modularity Installation and
Configuration Guide
Cisco IOS Software Modularity Command Reference
Cisco IOS Terminal Services Configuration Guide
Cisco IOS Terminal Services Command Reference
An orchestrated collection of processes and components to
activate Cisco IOS software feature sets by obtaining and
validating Cisco software licenses.
Installation and basic configuration of software modularity
images, including installations on single and dual route
processors, installation rollbacks, software modularity binding,
software modularity processes and patches.
DEC, local-area transport (LAT), and X.25 packet
assembler/disassembler (PAD).
Cisco IOS XE Terminal Services Command Reference
Cisco IOS Virtual Switch Command Reference
Virtual switch redundancy, high availability, and packet handling;
converting between standalone and virtual switch modes; virtual
switch link (VSL); Virtual Switch Link Protocol (VSLP).
Note
Cisco IOS Voice Configuration Library
Cisco IOS Voice Command Reference
Cisco IOS VPDN Configuration Guide
Cisco IOS XE VPDN Configuration Guide
Cisco IOS VPDN Command Reference
For information about virtual switch configuration, refer
to the product-specific software configuration
information for the Cisco Catalyst 6500 series switch or
for the Metro Ethernet 6500 series switch.
Cisco IOS support for voice call control protocols, interoperability,
physical and virtual interface management, and troubleshooting.
The library includes documentation for IP telephony applications.
Layer 2 Tunneling Protocol (L2TP) dial-out load balancing and
redundancy, L2TP extended failover, L2TP security VPDN,
multihop by Dialed Number Identification Service (DNIS),
timer and retry enhancements for L2TP and Layer 2 Forwarding
(L2F), RADIUS Attribute 82: tunnel assignment ID, shell-based
authentication of VPDN users, tunnel authentication via
RADIUS on tunnel terminator.
Cisco IOS Wide-Area Networking Configuration Guide
Frame Relay, Layer 2 Tunneling Protocol Version 3 (L2TPv3),
Link Access Procedure, Balanced (LAPB), Switched
Cisco IOS XE Wide-Area Networking Configuration Guide
Multimegabit Data Service (SMDS), and X.25.
Cisco IOS Wide-Area Networking Command Reference
Cisco IOS Wireless LAN Configuration Guide
Cisco IOS Wireless LAN Command Reference
x
Broadcast key rotation, IEEE 802.11x support, IEEE 802.1x
authenticator, IEEE 802.1x local authentication service for
Extensible Authentication Protocol-Flexible Authentication via
Secure Tunneling (EAP-FAST), Multiple Basic Service Set ID
(BSSID), Wi-Fi Multimedia (WMM) required elements, and
Wi-Fi Protected Access (WPA).
About Cisco IOS and Cisco IOS XE Software Documentation
Additional Resources and Documentation Feedback
Table 2
Cisco IOS Supplementary Documents and Resources
Document Title
Description
Cisco IOS Master Command List, All Releases
Alphabetical list of all the commands documented in all
Cisco IOS releases.
Cisco IOS New, Modified, Removed, and
Replaced Commands
List of all the new, modified, removed, and replaced commands
for a Cisco IOS release.
Cisco IOS Software System Messages
List of Cisco IOS system messages and descriptions. System
messages may indicate problems with your system; be
informational only; or may help diagnose problems with
communications lines, internal hardware, or the
system software.
Cisco IOS Debug Command Reference
Alphabetical list of debug commands including brief
descriptions of use, command syntax, and usage guidelines.
Release Notes and Caveats
Information about new and changed features, system
requirements, and other useful information about specific
software releases; information about defects in specific
Cisco IOS software releases.
MIBs
Files used for network monitoring. To locate and download
MIBs for selected platforms, Cisco IOS releases, and feature
sets, use Cisco MIB Locator at the following URL:
http://www.cisco.com/go/mibs
RFCs
Standards documents maintained by the Internet Engineering
Task Force (IETF) that Cisco IOS documentation references
where applicable. The full text of referenced RFCs may be
obtained at the following URL:
http://www.rfc-editor.org/
Additional Resources and Documentation Feedback
What’s New in Cisco Product Documentation is published monthly and describes all new and revised
Cisco technical documentation. The What’s New in Cisco Product Documentation publication also
provides information about obtaining the following resources:
•
Technical documentation
•
Cisco product security overview
•
Product alerts and field notices
•
Technical assistance
Cisco IOS technical documentation includes embedded feedback forms where you can rate documents
and provide suggestions for improvement. Your feedback helps us improve our documentation.
xi
About Cisco IOS and Cisco IOS XE Software Documentation
Additional Resources and Documentation Feedback
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, the Cisco logo, DCE, and Welcome to the
Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar,
Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified
Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration
Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient,
IOS, iPhone, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone,
MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect,
ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and
the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply
a partnership relationship between Cisco and any other company. (0807R)
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.
© 2007–2008 Cisco Systems, Inc. All rights reserved.
xii
Using the Command-Line Interface in Cisco IOS
and Cisco IOS XE Software
Last updated: August 6, 2008
This document provides basic information about the command-line interface (CLI) in Cisco IOS and
Cisco IOS XE software and how you can use some of the CLI features. This document contains the
following sections:
•
Initially Configuring a Device, page i
•
Using the CLI, page ii
•
Saving Changes to a Configuration, page xii
•
Additional Information, page xii
For more information about using the CLI, see the “Using the Cisco IOS Command-Line Interface”
section of the Cisco IOS Configuration Fundamentals Configuration Guide.
For information about the software documentation set, see the “About Cisco IOS and Cisco IOS XE
Software Documentation” document.
Initially Configuring a Device
Initially configuring a device varies by platform. For information about performing an initial
configuration, see the hardware installation documentation that is provided with the original packaging
of the product or go to the Product Support area of Cisco.com at
http://www.cisco.com/web/psa/products/index.html.
After you have performed the initial configuration and connected the device to your network, you can
configure the device by using the console port or a remote access method, such as Telnet or Secure Shell
(SSH), to access the CLI or by using the configuration method provided on the device, such as Security
Device Manager.
i
Using the Command-Line Interface in Cisco IOS and Cisco IOS XE Software
Using the CLI
Changing the Default Settings for a Console or AUX Port
There are only two changes that you can make to a console port and an AUX port:
Note
•
Change the port speed with the config-register 0x command. Changing the port speed is not
recommended. The well-known default speed is 9600.
•
Change the behavior of the port; for example, by adding a password or changing the timeout value.
The AUX port on the Route Processor (RP) installed in a Cisco ASR1000 series router does not serve
any useful customer purpose and should be accessed only under the advisement of a customer support
representative.
Using the CLI
This section describes the following topics:
•
Understanding Command Modes, page ii
•
Using the Interactive Help Feature, page v
•
Understanding Command Syntax, page vi
•
Understanding Enable and Enable Secret Passwords, page viii
•
Using the Command History Feature, page viii
•
Abbreviating Commands, page ix
•
Using Aliases for CLI Commands, page ix
•
Using the no and default Forms of Commands, page x
•
Using the debug Command, page x
•
Filtering Output Using Output Modifiers, page x
•
Understanding CLI Error Messages, page xi
Understanding Command Modes
The CLI command mode structure is hierarchical, and each mode supports a set of specific commands.
This section describes the most common of the many modes that exist.
Table 1 lists common command modes with associated CLI prompts, access and exit methods, and a
brief description of how each mode is used.
ii
Using the Command-Line Interface in Cisco IOS and Cisco IOS XE Software
Using the CLI
Table 1
CLI Command Modes
Command
Mode
Access Method
Prompt
Exit Method
User EXEC
Log in.
Router>
Issue the logout or exit
command.
Privileged
EXEC
From user EXEC mode,
issue the enable
command.
Router#
Issue the disable
command or the exit
command to return to
user EXEC mode.
Mode Usage
•
Change terminal
settings.
•
Perform basic tests.
•
Display device status.
•
Issue show and debug
commands.
•
Copy images to the
device.
•
Reload the device.
•
Manage device
configuration files.
•
Manage device file
systems.
Global
configuration
From privileged EXEC
mode, issue the
configure terminal
command.
Router(config)#
Issue the exit command Configure the device.
or the end command to
return to privileged
EXEC mode.
Interface
configuration
From global
configuration mode,
issue the interface
command.
Router(config-if)#
Issue the exit command Configure individual
to return to global
interfaces.
configuration mode or
the end command to
return to privileged
EXEC mode.
Line
configuration
Router(config-line)# Issue the exit command Configure individual
From global
to return to global
terminal lines.
configuration mode,
configuration mode or
issue the line vty or line
the end command to
console command.
return to privileged
EXEC mode.
iii
Using the Command-Line Interface in Cisco IOS and Cisco IOS XE Software
Using the CLI
Table 1
CLI Command Modes (continued)
Command
Mode
Access Method
Prompt
Exit Method
ROM monitor
From privileged EXEC
mode, issue the reload
command. Press the
Break key during the
first 60 seconds while
the system is booting.
rommon # >
Issue the continue
command.
Diagnostic
(available only
on the Cisco
ASR1000
series router)
Router(diag)#
The router boots or
enters diagnostic mode
in the following
scenarios. When a
Cisco IOS process or
processes fail, in most
scenarios the router will
reload.
•
•
•
iv
The # symbol
represents the line
number and increments
at each prompt.
A user-configured
access policy was
configured using
the transport-map
command, which
directed the user
into diagnostic
mode.
The router was
accessed using an
RP auxiliary port.
A break signal
(Ctrl-C,
Ctrl-Shift-6, or the
send break
command) was
entered, and the
router was
configured to enter
diagnostic mode
when the break
signal was received.
If a Cisco IOS process
failure is the reason for
entering diagnostic
mode, the failure must
be resolved and the
router must be rebooted
to exit diagnostic mode.
If the router is in
diagnostic mode
because of a
transport-map
configuration, access
the router through
another port or using a
method that is
configured to connect to
the Cisco IOS CLI.
If the RP auxiliary port
was used to access the
router, use another port
for access. Accessing
the router through the
auxiliary port is not
useful for customer
purposes.
Mode Usage
•
Run as the default
operating mode when a
valid image cannot be
loaded.
•
Access the fall-back
procedure for loading an
image when the device
lacks a valid image and
cannot be booted.
•
Perform password
recovery when a
CTRL-Break sequence is
issued within 60 seconds
of a power-on or reload
event.
•
Inspect various states on
the router, including the
Cisco IOS state.
•
Replace or roll back the
configuration.
•
Provide methods of
restarting the Cisco IOS
software or other
processes.
•
Reboot hardware, such
as the entire router, an
RP, an ESP, a SIP, a SPA,
or possibly other
hardware components.
•
Transfer files into or off
of the router using
remote access methods
such as FTP, TFTP, and
SCP.
Using the Command-Line Interface in Cisco IOS and Cisco IOS XE Software
Using the CLI
EXEC commands are not saved when the software reboots. Commands that you issue in a configuration
mode can be saved to the startup configuration. If you save the running configuration to the startup
configuration, these commands will execute when the software is rebooted. Global configuration mode
is the highest level of configuration mode. From global configuration mode, you can enter a variety of
other configuration modes, including protocol-specific modes.
ROM monitor mode is a separate mode that is used when the 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. Use the question symbol (?) to view the commands that
you can use while the device is in ROM monitor mode.
rommon 1 > ?
alias
boot
confreg
cont
context
cookie
.
.
.
rommon 2 >
set and display aliases command
boot up an external process
configuration register utility
continue executing a downloaded image
display the context of a loaded image
display contents of cookie PROM in hex
The following example shows how the command prompt changes to indicate a different command mode:
Router> enable
Router# configure terminal
Router(config)# interface ethernet 1/1
Router(config-if)# ethernet
Router(config-line)# exit
Router(config)# end
Router#
Note
A keyboard alternative to the end command is Ctrl-Z.
Using the Interactive Help Feature
The CLI includes an interactive Help feature. Table 2 describes how to use the Help feature.
Table 2
CLI Interactive Help Commands
Command
Purpose
help
Provides a brief description of the help feature in any command mode.
?
Lists all commands available for a particular command mode.
partial command?
Provides a list of commands that begin with the character string (no
space between the command and the question mark).
partial command<Tab>
Completes a partial command name (no space between the command
and <Tab>).
command ?
Lists the keywords, arguments, or both associated with the command
(space between the command and the question mark).
command keyword ?
Lists the arguments that are associated with the keyword (space between
the keyword and the question mark).
v
Using the Command-Line Interface in Cisco IOS and Cisco IOS XE Software
Using the CLI
The following examples show how to use the help commands:
help
Router> help
Help may be requested at any point in a command by entering a question mark '?'. If
nothing matches, the help list will be empty and you must backup until entering a '?'
shows the available options.
Two styles of help are provided:
1. Full help is available when you are ready to enter a command argument (e.g. 'show ?')
and describes each possible argument.
2. Partial help is provided when an abbreviated argument is entered and you want to know
what arguments match the input (e.g. 'show pr?'.)
?
Router# ?
Exec commands:
access-enable
access-profile
access-template
alps
archive
<snip>
Create a temporary access-List entry
Apply user-profile to interface
Create a temporary access-List entry
ALPS exec commands
manage archive files
partial command?
Router(config)# zo?
zone zone-pair
partial command<Tab>
Router(config)# we<Tab> webvpn
command ?
Router(config-if)# pppoe ?
enable
Enable pppoe
max-sessions Maximum PPPOE sessions
command keyword ?
Router(config-if)# pppoe enable ?
group attach a BBA group
<cr>
Understanding Command Syntax
Command syntax is the format in which a command should be entered in the CLI. Commands include
the name of the command, keywords, and arguments. Keywords are alphanumeric strings that are used
literally. Arguments are placeholders for values that a user must supply. Keywords and arguments may
be required or optional.
Specific conventions convey information about syntax and command elements. Table 3 describes these
conventions.
vi
Using the Command-Line Interface in Cisco IOS and Cisco IOS XE Software
Using the CLI
Table 3
CLI Syntax Conventions
Symbol/Text
Function
Notes
< > (angle brackets)
Indicate that the option is an
argument.
Sometimes arguments are displayed
without angle brackets.
A.B.C.D.
Indicates that you must enter a
dotted decimal IP address.
Angle brackets (< >) are not always
used to indicate that an IP address is
an argument.
WORD (all capital letters)
Indicates that you must enter
one word.
Angle brackets (< >) are not always
used to indicate that a WORD is an
argument.
LINE (all capital letters)
Indicates that you must enter
more than one word.
Angle brackets (< >) are not always
used to indicate that a LINE is an
argument.
<cr> (carriage return)
Indicates the end of the list of —
available keywords and arguments, and also indicates when
keywords and arguments are
optional. When <cr> is the only
option, you have reached the
end of the branch or the end of
the command if the command
has only one branch.
The following examples show syntax conventions:
Router(config)# ethernet cfm domain ?
WORD domain name
Router(config)# ethernet cfm domain dname ?
level
Router(config)# ethernet cfm domain dname level ?
<0-7> maintenance level number
Router(config)# ethernet cfm domain dname level 7 ?
<cr>
Router(config)# snmp-server file-transfer access-group 10 ?
protocol protocol options
<cr>
Router(config)# logging host ?
Hostname or A.B.C.D IP address of the syslog server
ipv6
Configure IPv6 syslog server
Router(config)# snmp-server file-transfer access-group 10 ?
protocol protocol options
<cr>
vii
Using the Command-Line Interface in Cisco IOS and Cisco IOS XE Software
Using the CLI
Understanding Enable and Enable Secret Passwords
Some privileged EXEC commands are used for actions that impact the system, and it is recommended
that you set a password for these commands to prevent unauthorized use. Two types of passwords, enable
(not encrypted) and enable secret (encrypted), can be set. The following commands set these passwords
and are issued in global configuration mode:
•
enable password
•
enable secret password
Using an enable secret password is recommended because it is encrypted and more secure than the
enable password. When you use an enable secret password, text is encrypted (unreadable) before it is
written to the config.text file. When you use an enable password, the text is written as entered (readable)
to the config.text file.
Each type of password is case sensitive, can contain from 1 to 25 uppercase and lowercase alphanumeric
characters, and can start with a number. Spaces are also valid password characters; for example,
“two words” is a valid password. Leading spaces are ignored, but trailing spaces are recognized.
Note
Both password commands have numeric keywords that are single integer values. If you choose a number
for the first character of your password followed by a space, the system will read the number as if it were
the numeric keyword and not as part of your password.
When both passwords are set, the enable secret password takes precedence over the enable password.
To remove a password, use the no form of the commands: no enable password or
no enable secret password.
For more information about password recovery procedures for Cisco products, see
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/
products_tech_note09186a00801746e6.shtml.
Using the Command History Feature
The CLI command history feature saves the commands you enter during a session in a command history
buffer. The default number of commands saved is 10, but the number is configurable within the range of
0 to 256. This command history feature is particularly useful for recalling long or complex commands.
To change the number of commands saved in the history buffer for a terminal session, issue the
terminal history size command:
Router# terminal history size num
A command history buffer is also available in line configuration mode with the same default and
configuration options. To set the command history buffer size for a terminal session in line configuration
mode, issue the history command:
Router(config-line)# history [size num]
To recall commands from the history buffer, use the following methods:
•
viii
Press Ctrl-P or the up arrow key—Recalls commands beginning with the most recent command.
Repeat the key sequence to recall successively older commands.
Using the Command-Line Interface in Cisco IOS and Cisco IOS XE Software
Using the CLI
•
Press Ctrl-N or the down arrow key—Recalls the most recent commands in the history buffer after
they have been recalled using Ctrl-P or the up arrow key. Repeat the key sequence to recall
successively more recent commands.
Note
•
The arrow keys function only on ANSI-compatible terminals such as the VT100.
Issue the show history command in user EXEC or privileged EXEC mode—Lists the most recent
commands that you entered. The number of commands that are displayed is determined by the
setting of the terminal history size and history commands.
The CLI command history feature is enabled by default. To disable this feature for a terminal
session, issue the terminal no history command in user EXEC or privileged EXEC mode or the
no history command in line configuration mode.
Abbreviating Commands
Typing a complete command name is not always required for the command to execute. The CLI
recognizes an abbreviated command when the abbreviation contains enough characters to uniquely
identify the command. For example, the show version command can be abbreviated as sh ver. It cannot
be abbreviated as s ver because s could mean show, set, or systat. The sh v abbreviation also is not valid
because the show command has vrrp as a keyword in addition to version. (Command and keyword
examples from Cisco IOS Release 12.4(13)T.)
Using Aliases for CLI Commands
To save time and the repetition of entering the same command multiple times, you can use a command
alias. An alias can be configured to do anything that can be done at the command line, but an alias cannot
move between modes, type in passwords, or perform any interactive functions.
Table 4 shows the default command aliases.
Table 4
Default Command Aliases
Command Alias
Original Command
h
help
lo
logout
p
ping
s
show
u or un
undebug
w
where
To create a command alias, issue the alias command in global configuration mode. The syntax of the
command is alias mode command-alias original-command. Following are some examples:
•
Router(config)# alias exec prt partition—privileged EXEC mode
•
Router(config)# alias configure sb source-bridge—global configuration mode
•
Router(config)# alias interface rl rate-limit—interface configuration mode
ix
Using the Command-Line Interface in Cisco IOS and Cisco IOS XE Software
Using the CLI
To view both default and user-created aliases, issue the show alias command.
For more information about the alias command, see
http://www.cisco.com/en/US/docs/ios/fundamentals/command/reference/cf_book.html.
Using the no and default Forms of Commands
Most configuration commands have a no form that is used to reset a command to its default value or
disable a feature or function. For example, the ip routing command is enabled by default. To disable this
command, you would issue the no ip routing command. To re-enable IP routing, you would issue the
ip routing command.
Configuration commands may also have a default form, which returns the command settings to their
default values. For commands that are disabled by default, using the default form has the same effect as
using the no form of the command. For commands that are enabled by default and have default settings,
the default form enables the command and returns the settings to their default values.
The no and default forms of commands are described in the command pages of command references.
Using the debug Command
A debug command produces extensive output that helps you troubleshoot problems in your network.
These commands are available for many features and functions within Cisco IOS and Cisco IOS XE
software. Some debug commands are debug all, debug aaa accounting, and debug mpls packets. To
use debug commands during a Telnet session with a device, you must first enter the terminal monitor
command. To turn off debugging completely, you must enter the undebug all command.
For more information about debug commands, see the Cisco IOS Debug Command Reference at
http://www.cisco.com/en/US/docs/ios/debug/command/reference/db_book.html.
Caution
Debugging is a high priority and high CPU utilization process that can render your device unusable. Use
debug commands only to troubleshoot specific problems. The best times to run debugging are during
periods of low network traffic and when few users are interacting with the network. Debugging during
these periods decreases the likelihood that the debug command processing overhead will affect network
performance or user access or response times.
Filtering Output Using Output Modifiers
Many commands produce lengthy output that may use several screens to display. Using output modifiers,
you can filter this output to show only the information that you want to see.
Three output modifiers are available and are described as follows:
x
•
begin regular expression—Displays the first line in which a match of the regular expression is found
and all lines that follow.
•
include regular expression—Displays all lines in which a match of the regular expression is found.
•
exclude regular expression—Displays all lines except those in which a match of the regular
expression is found.
Using the Command-Line Interface in Cisco IOS and Cisco IOS XE Software
Using the CLI
To use one of these output modifiers, type the command followed by the pipe symbol (|), the modifier,
and the regular expression that you want to search for or filter. A regular expression is a case-sensitive
alphanumeric pattern. It can be a single character or number, a phrase, or a more complex string.
The following example illustrates how to filter output of the show interface command to display only
lines that include the expression “protocol.”
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
Understanding CLI Error Messages
You may encounter some error messages while using the CLI. Table 5 shows the common CLI error
messages.
Table 5
Common CLI Error Messages
Error Message
Meaning
% Ambiguous command:
“show con”
You did not enter enough
Reenter the command followed by a
characters for the command to space and a question mark (?). The
be recognized.
keywords that you are allowed to
enter for the command appear.
% Incomplete command.
You did not enter all the
keywords or values required
by the command.
% Invalid input detected at “^” You entered the command inmarker.
correctly. The caret (^) marks
the point of the error.
How to Get Help
Reenter the command followed by a
space and a question mark (?). The
keywords that you are allowed to
enter for the command appear.
Enter a question mark (?) to display
all the commands that are available in
this command mode. The keywords
that you are allowed to enter for the
command appear.
For more system error messages, see the following documents:
•
Cisco IOS Release 12.2SR System Message Guide
•
Cisco IOS System Messages, Volume 1 of 2 (Cisco IOS Release 12.4)
•
Cisco IOS System Messages, Volume 2 of 2 (Cisco IOS Release 12.4)
xi
Using the Command-Line Interface in Cisco IOS and Cisco IOS XE Software
Saving Changes to a Configuration
Saving Changes to a Configuration
To save changes that you made to the configuration of a device, you must issue the copy running-config
startup-config command or the copy system:running-config nvram:startup-config command. When
you issue these commands, the configuration changes that you made are saved to the startup
configuration and saved when the software reloads or power to the device is turned off or interrupted.
The following example shows the syntax of the copy running-config startup-config command:
Router# copy running-config startup-config
Destination filename [startup-config]?
You press Enter to accept the startup-config filename (the default), or type a new filename and then press
Enter to accept that name. The following output is displayed indicating that the configuration was saved:
Building configuration...
[OK]
Router#
On most platforms, the configuration is saved to NVRAM. On platforms with a Class A flash file system,
the configuration is saved to the location specified by the CONFIG_FILE environment variable. The
CONFIG_FILE variable defaults to NVRAM.
Additional Information
•
“Using the Cisco IOS Command-Line Interface” section of the
Cisco IOS Configuration Fundamentals Configuration Guide:
http://www.cisco.com/en/US/docs/ios/fundamentals/configuration/guide/cf_cli-basics.html
or
“Using Cisco IOS XE Software” chapter of the Cisco ASR1000 Series Aggregation Services Routers
Software Configuration Guide:
http://www.cisco.com/en/US/docs/routers/asr1000/configuration/guide/chassis/using_cli.html
•
Cisco Product Support Resources
http://www.cisco.com/web/psa/products/index.html
•
Support area on Cisco.com (also search for documentation by task or product)
http://www.cisco.com/en/US/support/index.html
•
White Paper: Cisco IOS Reference Guide
http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_white_paper09186a00801830
5e.shtml
•
Software Download Center (downloads; tools; licensing, registration, advisory, and general
information) (requires Cisco.com User ID and password)
http://www.cisco.com/kobayashi/sw-center/
•
Error Message Decoder, a tool to help you research and resolve error messages for
Cisco IOS software
http://www.cisco.com/pcgi-bin/Support/Errordecoder/index.cgi
xii
Using the Command-Line Interface in Cisco IOS and Cisco IOS XE Software
Additional Information
•
Command Lookup Tool, a tool to help you find detailed descriptions of Cisco IOS commands
(requires Cisco.com user ID and password)
http://tools.cisco.com/Support/CLILookup
•
Output Interpreter, a troubleshooting tool that analyzes command output of supported
show commands
https://www.cisco.com/pcgi-bin/Support/OutputInterpreter/home.pl\
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, the Cisco logo, DCE, and Welcome to the
Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar,
Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified
Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration
Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient,
IOS, iPhone, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone,
MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect,
ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and
the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply
a partnership relationship between Cisco and any other company. (0807R)
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.
© 2007–2008 Cisco Systems, Inc. All rights reserved.
xiii
Using the Command-Line Interface in Cisco IOS and Cisco IOS XE Software
Additional Information
xiv
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 1 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 1 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.
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Service Selection Gateway Features Roadmap
Table 1
Release
Supported SSG Features
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
Configuring a
The SSG Per Session Firewall feature enables you to
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
Communication
2
The Initial SSG Communication feature comprises initial Implementing SSG:
Initial Tasks
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.
RADIUS Profiles and
Attributes for SSG
RADIUS Profiles and
Attributes for SSG
SSG uses RADIUS Profiles and attributes for the
authentication, authorization, and accounting of
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
Host-Key
Implementing SSG:
The SSG Port-Bundle Host Key feature enhances
Initial Tasks
communication and functionality between the Service
Selection Gateway (SSG) and the Cisco Subscriber Edge
Services Manager (SESM) by introducing a mechanism
that uses the host source IP address and source port to
identify and monitor subscribers.
SSG Prepaid Tariff
Switching
The SSG Prepaid Tariff Switching feature allows changes Configuring SSG
in tariffs during the lifetime of a connection.
Accounting
Service Selection Gateway Features Roadmap
Table 1
Release
Supported SSG Features (continued)
Feature Name
12.2(13)T SSG Accounting Update
Interval Per Service
Feature Description
Where Documented
The SSG Accounting Update Interval Per Service feature Configuring SSG
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
Proxy RADIUS
The SSG AutoLogon Using Proxy RADIUS feature
enables SSG to act as a RADIUS proxy for non-SSD
clients whose Access-Requests do not contain VSAs.
SSG Hierarchical
Policing
Configuring SSG
The SSG Hierarchical Policing feature ensures that a
Hierarchical Policing
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.
Configuring SSG to Serve
as a RADIUS Proxy
3
Service Selection Gateway Features Roadmap
Table 1
Supported SSG Features (continued)
Release
Feature Name
12.3(4)T
Postpaid Tariff Switching The Postpaid Tariff Switching for SSG feature allows
for SSG
changes in tariffs during the lifetime of a connection.
Configuring SSG
Accounting
PPP Subscriber Access
The PPP subscriber access feature supports PPP as a
subscriber access protocol.
Configuring SSG to
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
for Proxy RADIUS
This feature allows you to configure multiple AAA
servers. You can configure each remote RADIUS server
with timeout and retransmission parameters. SSG will
perform failover among the servers in the predefined
group.
Configuring SSG to Serve
as a RADIUS Proxy
SSG Autologoff
The SSG Autologoff feature supports methods to log
subscribers out of SSG.
Configuring SSG to Log
Off Subscribers
SSG Direction
Configuration for
Interfaces and Ranges
Implementing SSG:
SSG implements service selection through selective
Initial Tasks
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.
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
Enhancements
The SSG Prepaid Enhancements feature adds support for Configuring SSG
Accounting
prepaid tariff switching, postpaid tariff switching, and
simultaneous volume- and time-based prepaid billing to
the existing SSG Prepaid feature.
4
Feature Description
Where Documented
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.
Configuring SSG
Accounting
SSG Proxy for
CDMA2000
This feature enables service selection in CDMA2000
networks through enhancements to the SSG RADIUS
Proxy functionality.
Configuring SSG to Serve
as a RADIUS Proxy
SSG Service Profile
Caching
The Service Profile Cache feature enables SSG to use a Configuring SSG for
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
Unused Accounting
Records
The SSG Suppression of Unused Accounting Records
Configuring SSG
feature allows you to turn off unneeded Service Selection Accounting
Gateway (SSG) accounting records.
Service Selection Gateway Features Roadmap
Table 1
Supported SSG Features (continued)
Release
Feature Name
Feature Description
Where Documented
12.3(7)T
SSG Service Logon
Enhancements
The SSG Service Logon Enhancements feature enables
SSG to deliver services to a subscriber after receiving
valid authentication information.
Configuring SSG for
Subscriber Services
SSG 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.
Configuring SSG to
Authenticate Subscribers
with Transparent
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.
SSG Interface
Redundancy
SSG interface redundancy allows services to be
Implementing SSG:
associated with more than one interface to protect against Initial Tasks
link failures.
12.3(8)T
Configuring SSG
Accounting
12.3(11)T SSG Default Quota for
Prepaid Billing Server
Failure
The SSG Default Quota for Prepaid Billing Server
Failure feature enables SSG to be configured to allocate
a default quota when the prepaid server fails to respond
to an authorization request.
12.3(14)T Extended Prepaid Tariff
Switching for SSG
Configuring SSG
The Extended Prepaid Tariff Switch for SSG feature is
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
Authentication for SSG
Configuring SSG for
The MAC-Address-Based 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
Renewal for SSG
The SSG 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.
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
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.
Configuring SSG for
On-Demand IP Address
Renewal
Configuring SSG Support
for Subnet-Based
Authentication
5
Service Selection Gateway Features Roadmap
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
6
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 1
•
Restrictions for SSG, page 1
•
Information About SSG, page 2
•
Where to Go Next, page 8
•
Additional References, page 8
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.
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Overview of SSG
Information About 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 2
•
Benefits of Using SSG, page 3
•
Components of a Subscriber Edge Services Solution, page 4
•
Subscriber Edge Services Network Architecture, page 6
•
How Does SSG Work?, page 7
•
SSG Network Deployments, page 7
•
SSG Supported Access Protocols, page 7
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.
2
Overview of SSG
Information About SSG
Figure 1
Delivering Network Services with Cisco SESM and SSG
Registration
SESM
- Personalized content
- List of subscribed services
- Access to walled gardens
- On-demand, billable services
Mobile
Access Wi-Fi
networks DSL
Cable
Ethernet
Laptop
PDA
Cisco SSG
Mobile
Internet
Walled gardens
Weather
Flight info
Basic
Internet
Video Voice
Premium
services
127101
Reservations
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.
3
Overview of SSG
Information About 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:
4
•
SSG, page 5
•
SESM, page 5
•
AAA Server, page 5
•
Services, page 5
Overview of SSG
Information About 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
5
Overview of SSG
Information About 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
PC
Directory
Server
SESM
Corporate
VPN
DSL
WAP
SSG
Internet
GGSN
PDA
Gaming
Wireless LAN
Subscriber access media
6
Services selection
Services
127102
Open
garden
Notebook
Overview of SSG
Information About 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
7
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.
8
Overview of SSG
Additional References
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
Configuration Guide, Release 12.4
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,
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.
http://www.cisco.com/public/support/tac/home.shtml
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
9
Overview of SSG
Additional References
10
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
This module was first published on May 2, 2005, and last updated on May 2, 2005.
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 24.
Contents
•
Prerequisites for Implementing SSG, page 1
•
Restrictions for Implementing SSG, page 2
•
How to Establish Initial SSG Communication, page 2
•
Configuration Examples for Establishing Initial SSG Communication, page 19
•
Where To Go Next, page 23
•
Additional References, page 23
•
Feature Information for Implementing SSG, page 24
Prerequisites for Implementing SSG
Knowledge
Before configuring SSG, you should understand the concepts in Overview of SSG.
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Implementing SSG: Initial Tasks
Restrictions for Implementing SSG
Interfaces
SSG is supported on all logical and physical interfaces on which Cisco Express Forwarding (CEF)
switching is supported. This includes physical interfaces such as ATM, Ethernet, and
Packet-over-SONET (POS), and logical interfaces such as GRE, 802.1q virtual LANs, and
Point-to-Point Protocol (PPPoX).
CEF Switching
IP CEF must be enabled globally before SSG will work.
Cisco Subscriber Edge Services Manager
If you want to perform Layer 3 service selection, you must install and configure Cisco SESM as
described in the Cisco Subscriber Edge Services Manager Administration and Configuration Guide.
AAA or LDAP
An authentication, authorization, and accounting (AAA) RADIUS server or LDAP server are typically
used to authenticate subscribers and to store subscriber and service profiles.
Restrictions for Implementing SSG
SSG does not process IP multicast packets. IP multicast packets will be handled by Cisco IOS software
in the traditional way.
How to Establish Initial SSG Communication
To enable SSG and establish SSG communication with other network devices, perform the tasks in the
following sections:
•
Enabling SSG, page 2
•
System Resource Cleanup When SSG Is Unconfigured, page 3
•
Configuring the Default Network, page 9
•
Configuring SSG Communication with SESM:
– Configuring SSG-SESM API Communication, page 10
– Configuring SSG Port-Bundle Host-Key Functionality, page 11
•
Configuring SSG to AAA Server Interaction, page 17
•
Troubleshooting Initial SSG Communication, page 19
Enabling SSG
Perform this task to enter global configuration and enable SSG on the router.
Note
2
This task must be performed before any other SSG functionality can be configured.
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
SSG and Cisco Express Forwarding
SSG works with CEF switching technology to provide maximum Layer 3 switching performance.
Because CEF is topology-driven rather than traffic-driven, its performance is unaffected by network size
or dynamics. CEF must be enabled for SSG to work.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
ip cef
4.
ssg enable
DETAILED STEPS
Step 1
Command or Action
Purpose
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
Enables global IP CEF.
ip cef
Example:
Router(config)ip cef
Step 4
Enables SSG.
ssg enable
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 4
•
Uplink Interface Redundancy Overview, page 4
3
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
•
Downlink Interface Redundancy Overview, page 5
•
SSG Uplink Interface Redundancy Topologies, page 5
•
Restrictions, page 6
Perform the following tasks to configure SSG interfaces:
•
Setting SSG Interface Direction for an Individual Interface, page 7
•
Setting the Direction on an ATM Subinterface (with PVC or PVC Range), page 7
•
Verifying SSG Interface Binding, page 9
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 7
4
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
Downlink Interface Redundancy Overview
Subscriber traffic can be received by SSG on any of the downlink configured interfaces, which allows
for downlink interface redundancy.
The SSG Downlink Interface Redundancy feature can be configured with or without the Port-Bundle
Host-Key (PBHK) feature. When PBHK is disabled, downlink interface redundancy is the default
behavior. When PBHK is enabled, you must disable SSG’s support of overlapping host IP addresses with
the no host overlap command. For more information on configuring PBHK, see the “Configuring SSG
Port-Bundle Host-Key Functionality” section on page 11.
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 5
•
Multiple Uplink Interfaces with a Single Next Hop, page 5
•
Multiple Uplink Interfaces with No Next Hop, page 6
•
Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops, page 6
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
Service
Uplink 2
Next hop 2
103656
SSG
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.
5
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
Figure 4
Multiple Uplink Interfaces with a Single Next Hop: Sample Topology
SSG
Next hop
Service
Uplink 2
103657
Uplink 1
Multiple Uplink Interfaces with No Next Hop
Figure 5 shows an example of SSG interface redundancy configured to support multiple uplink
interfaces that are directly connected to the service.
Figure 5
Multiple Uplink Interfaces with No Next Hop: Sample Topology
SSG
Service
Uplink 2
103658
Uplink 1
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
SSG
Service
Uplink 2
103659
Uplink 1
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.
6
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
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
Command or Action
Purpose
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
group-name]}
Example:
Router(config-if)# ssg direction downlink
Step 3
Sets the direction of the interface.
•
An uplink interface is an interface to services; a
downlink interface is an interface to subscribers.
•
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.
(Optional) Exits to global configuration mode.
exit
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 7). However, if the point-to-point ATM subinterface contains a PVC range, this will result in
7
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
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
Command or Action
Purpose
interface atm
interface-number.subinterface-number {mpls |
multipoint | point-to-point}
Specifies a subinterface and enters subinterface
configuration mode.
Example:
Router(config)# interface ATM 1/0.1
point-to-point
Step 2
ssg direction {downlink | uplink [member
group-name]}
Sets the direction of the subinterfaces.
•
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
•
Example:
Use this command to define the permanent virtual
connection (PVC).
Router(config-subif)# pvc 1/32
Step 4
range [range-name] pvc start-vpi/start-vci
end-vpi/end-vci
Defines a PVC range.
•
Example:
Router(config-subif)# range MyRange pvc 1/32
1/42
8
Use this command if a range was not already defined.
You can also use this command after the ssg direction
command, with the same effect.
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
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
Command or Action
Purpose
show ssg interface [brief] [interface-type
interface-number]
Displays information about SSG interfaces.
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
Binding Type: Static
Interface: ATM4/0.140
Bind Direction: Uplink
Binding Type: Static
Services bound: NONE
Router# show ssg interface brief
Interface
Ethernet1/1
ATM4/0.40
ATM4/0.140
Direction
Downlink
Downlink
Uplink
Binding Type
Static
Static
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.
9
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
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
Command or Action
Purpose
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
SESM resides.
•
A mask provided with the IP address specifies
the range of IP addresses that users are able to
access without authentication.
Router(config)ssg default-network 10.10.1.2
255.255.255.255
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.
10
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
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
Command or Action
Purpose
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]
[acct-port UDP-port-number]
Example:
Specifies the port on which SSG will listen for SESM
commands (SSG is the server). The default port
number for authentication packets is 1645, and the
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:
Router(config)# ssg radius-helper validate
SSG will only accept commands from validated
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 12
•
Port-Bundle Length, page 12
•
Benefits of SSG Port-Bundle Host-Key, page 13
•
Prerequisites for SSG Port-Bundle Host-Key, page 14
•
Restrictions for SSG Port-Bundle Host-Key, page 14
Perform the following tasks to configure SSG Port-Bundle Host-Key functionality
•
Configuring the SSG Port-Bundle Host-Key, page 14 (required
•
Verifying SSG Port-Bundle Host-Key Configuration, page 16 (optional)
11
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
Port-Bundle Host-Key Mechanism
When the SSG Port-Bundle Host-Key feature is enabled, SSG performs port-address translation (PAT)
and network-address translation (NAT) on the HTTP traffic between the subscriber and the SESM server.
The operation of changing the subscriber’s IP address and port is commonly known as a port-map
operation, and the mappings between the original and changed IP address and port are known as
port-mappings.
When a subscriber sends traffic to the SESM server, SSG creates a port map that changes the source IP
address to a configured SSG source IP address and the source TCP port to a port allocated by SSG. SSG
assigns a range of ports, known as a port-bundle, to each subscriber because one subscriber can have
several simultaneous TCP sessions when accessing a web page. The assigned host-key, or combination
of SSG source IP address and port-bundle, uniquely identifies each subscriber.
When the Port-Bundle Host-Key feature is not enabled, the subscriber is uniquely identified by their IP
address. When the SESM server sends a reply to the subscriber, SSG translates the destination IP address
and TCP port to the subscriber’s actual IP address.
The host-key is carried in RADIUS packets sent between the SESM server and SSG in the Subscriber IP
vendor-specific attribute (VSA), and uniquely identifies the subscriber. Table 1 describes the Subscriber
IP VSA. When the SESM server sends a reply to the subscriber, SSG translates the destination IP address
and destination TCP port according to the port map.
Table 1
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.
12
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
Table 2
Note
Port-Bundle Lengths and Resulting Port-per-Bundle and Bundle-per-Group Values
Port-Bundle Length
(in bits)
Number of Ports
per Bundle
Number of Bundles per Group
(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
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.
13
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
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
14
1.
ssg port-map
2.
destination range port-range-start to port-range-end [ip ip-address]
3.
destination access-list access-list-number
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
4.
source ip {ip-address | interface}
5.
length bits
6.
no host overlap
7.
exit
DETAILED STEPS
Step 1
Command or Action
Purpose
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
port-range-end [ip ip-address]
Identifies packets for port-mapping by specifying the TCP
port range to compare against the subscriber traffic.
•
If the destination IP address is not configured, a default
network must be configured and routable from SSG in
order for this command to be effective.
•
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.
Example:
Router(config-ssg-portmap)# destination range
8080 to 8081
Step 3
destination access-list access-list-number
Example:
Router(config-ssg-portmap)# destination
access-list 100
Step 4
source ip {ip-address | interface}
Example:
Router(config-ssg-portmap)# source ip 10.0.50.1
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.
•
You can use multiple entries of the destination
access-list and destination range commands. The port
ranges and access lists are checked in the order in
which they are defined.
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.
•
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.
15
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
Step 5
Command or Action
Purpose
length bits
Router(config-ssg-portmap)# length 5
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
2^n ports per bundle.
no host overlap
Disables SSG support of overlapping host IP addresses.
Example:
Step 6
•
Example:
Router(config-ssg-portmap)# no host overlap
Use this command to enable subscriber-side interface
redundancy when SSG port-bundle host-key
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
70.13.60.2
Free Bundles
4032
Reserved Bundles
0
In-use Bundles
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:
Step 3
Port-bundle
Subscriber Address
Interface
64
10.10.3.1
Virtual-Access2
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
16
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
Subscriber Address = 10.10.3.1
Downlink Interface = Virtual-Access2
Port-mappings:Subscriber
Subscriber
Subscriber
Subscriber
Subscriber
Port:
Port:
Port:
Port:
Port:
3271
3272
3273
3274
3275
Mapped
Mapped
Mapped
Mapped
Mapped
Port:
Port:
Port:
Port:
Port:
1024
1025
1026
1027
1028
Configuring SSG to AAA Server Interaction
SSG communicates with a AAA server for authorization, authentication and accounting using the
RADIUS protocol. SSG and the AAA server interact to authenticate subscribers, and to retrieve
subscriber and service profiles. Perform this task to configure the shared key between SSG and the AAA
server.
Prerequisites
In order for SSG to communicate with SESM and the AAA servers, the AAA servers must be configured
correctly. See the Cisco IOS Security Configuration Guide and Cisco IOS Security Command Reference
for the AAA and RADIUS commands and tasks for configuring AAA servers.
SUMMARY STEPS
1.
ssg service-password password
DETAILED STEPS
Step 1
ssg service-password password
Example:
Router(config)# ssg service-password password
Sets the password used to authenticate the SSG with
the local AAA server while downloading service
profiles.
•
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]
17
Implementing SSG: Initial Tasks
How to Establish Initial SSG Communication
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
Command or Action
Purpose
show ssg connection ip-address service-name
[interface]
(Optional) Displays the connections of a given host and a
service name.
Example:
Router# show ssg connection 19.1.1.19 InstMsg
Step 2
show ssg host [ip-address [interface] |
username]
(Optional) Displays the information about a subscriber and
current connections of the subscriber.
Example:
Router# show ssg host 10.3.1.1
Step 3
show ssg port-map ip ip-address port
port-number
Example:
Router# show ssg port-map ip 10.13.60.2 port 64
Step 4
show ssg port-map status [free | reserved |
inuse]
Example:
Router# show ssg port-map status
Step 5
show ssg interface [interface | brief]
(Optional) Displays the following information about a port
bundle:
•
Port maps in the port bundle
•
Subscriber’s IP address
•
Interface through which the subscriber is connected
(Optional) Displays information on port-bundle groups,
including the following:
•
List of port-bundle groups
•
Port-bundle length
•
Number of free, reserved, and in-use port bundles in
each group
(Optional) Displays information about SSG interfaces.
•
Example:
Use this command without any keywords or arguments
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.
•
Example:
Router# show ssg summary
18
Use this command to display information such as which
SSG features are enabled, how many users are active,
how many services are active, and what filters are
active.
Implementing SSG: Initial Tasks
Configuration Examples for Establishing Initial SSG Communication
Step 7
Command or Action
Purpose
clear ssg connection ip-address service-name
[interface]
(Optional) Removes the connections of a given host and a
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
Command or Action
Purpose
debug radius
Displays debugging information associated with
RADIUS.
•
Example:
Router # debug radius
Step 2
debug ssg port-map {events | packets}
Use this command to troubleshoot
communication between SSG and the AAA
server.
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 20
•
SSG Interface Redundancy: Examples, page 20
•
SSG Port-Bundle Host-Key Configuration: Example, page 21
•
SSG and AAA Server Interaction Configuration: Example, page 21
•
Establishing Initial SSG Communication: Example, page 22
19
Implementing SSG: Initial Tasks
Configuration Examples for Establishing Initial SSG Communication
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 direction downlink
SSG Interface Redundancy: Examples
Service Bound to Multiple Uplink Interfaces: Example
In the following example, a service called “sample-service” is bound to two uplink interfaces:
ATM interface 1/0.1 is the primary interface, and ATM interface 1/0.2 is the secondary interface. Both
interfaces are configured as members of “groupA”.
ip cef
ssg enable
!
ssg bind service sample-service atm 1/0.1
ssg bind service sample-service atm 1/0.2 100
!
interface ATM 1/0.1 point-to-point
ip address 10.1.0.1 255.255.0.0
ssg direction uplink member groupA
!
interface ATM 1/0.2 point-to-point
ip address 10.2.0.1 255.255.0.0
ssg direction uplink member groupA
!
Service Bound to Next Hop with Multiple Uplink Interfaces: Example
In the following example, a service called “sample-serviceA” is bound to next-hop gateway 10.1.1.1.
Next-hop gateway 10.1.1.1 is reachable through two uplink interfaces: ethernet interface 1/0 and
Ethernet interface 2/0. The group name “service-groupA” indicates that both interfaces share the same
service (“sample-serviceA”).
For any services bound to either of the two interfaces, downstream traffic from the service is accepted
on either interface.
ip cef
ssg enable
!
ssg bind service sample-serviceA 10.1.1.1
20
Implementing SSG: Initial Tasks
Configuration Examples for Establishing Initial SSG Communication
!
interface ethernet 1/0
ip address 10.0.1.1 255.255.255.0
ssg direction uplink member service-groupA
!
interface ethernet 2/0
ip address 10.0.2.1 255.255.255.0
ssg direction uplink member service-groupA
!
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”).
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 serviceB 10.0.0.1
ssg bind service serviceB 20.0.0.1
!
interface ethernet 1/0
ip address 10.0.0.2 255.255.255.0
ssg direction uplink member groupB
!
interface ethernet 2/0
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)
21
Implementing SSG: Initial Tasks
Configuration Examples for Establishing Initial SSG Communication
!
aaa
aaa
aaa
aaa
aaa
!
new-model
authentication ppp default group radius
authorization network default group radius
authorization network ssg_aaa_author_internal_list none
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 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
!
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
ssg service-password servicecisco
22
Implementing SSG: Initial Tasks
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
destination range 80 to 80 ip 192.168.2.55
destination range 443 to 443 ip 192.168.2.55
destination range 8090 to 8101 ip 192.168.2.55
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
ssg direction downlink
!
! 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 host 192.168.2.62 auth-port 1812 acct-port 1813 key cisco
radius-server retransmit 5
radius-server timeout 30
radius-server key cisco
radius-server vsa send accounting
radius-server vsa send authentication
!
Where To Go Next
•
TBD
Additional References
The following sections provide references related to establishing SSG connectivity.
23
Implementing SSG: Initial Tasks
Feature Information for Implementing SSG
Related Documents
Related Topic
Document Title
SSG commands
Cisco IOS Service Selection Gateway Command Reference,
Release 12.4
SESM
Cisco Subscriber Edge Services Manager documentation.
RADIUS commands
Cisco IOS Security Command Reference, Release 12.4
RADIUS configuration tasks
Cisco IOS Security Configuration Guide, Release 12.4
MIBs
MIBs
MIBs Link
The Service Selection Gateway MIB enables network
administrators to use Simple Network Management
Protocol (SNMP) to monitor and manage SSG. The
SSG MIB contains objects that correspond to and allow
the monitoring of several important SSG features.
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
For detailed list of MIB objects and their definitions,
see the CISCO-SSG-MIB.
Technical Assistance
Description
Link
Technical Assistance Center (TAC) home page,
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.
http://www.cisco.com/public/support/tac/home.shtml
Feature Information for Implementing SSG
Table 3 lists the features in this module and provides links to specific configuration information. Only
features that were introduced or modified in Cisco IOS Release 12.2(1) or a later release appear in the
table.
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.
For information on a feature in this technology that is not documented here, see the Service Selection
Gateway Features Roadmap.
24
Implementing SSG: Initial Tasks
Feature Information for Implementing SSG
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.
Note
Table 3
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.
Feature Information for Implementing SSG: Initial Tasks
Feature Name
Releases
Feature Configuration Information
Initial SSG Communication
12.0(3)DC
12.3(4)B
12.2(11)T
12.3T
12.4
The Initial SSG Communication feature comprises initial
tasks you need to perform to enable SSG on the router and
to establish SSG communication with other key
components of the network, including Subscriber Edge
Services Manager (SESM) and the authentication,
authorization, and accounting (AAA) server.
The following sections provide information about this
feature:
SSG Direction Configuration for Interfaces and
Ranges
12.2T
12.3(4)T
•
Enabling SSG, page 2
•
Configuring the Default Network, page 9
•
Configuring SSG-SESM API Communication, page 10
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.
The following section provides information about this
feature:
•
SSG Interface Redundancy
12.3(8)T
Configuring SSG Interface Direction, page 3
SSG interface redundancy allows services to be associated
with more than one interface to protect against link failures.
The following section provides information about this
feature:
•
Uplink Interface Redundancy Overview, page 4
•
Downlink Interface Redundancy Overview, page 5
•
SSG Uplink Interface Redundancy Topologies, page 5
•
SSG Interface Redundancy: Examples, page 20
25
Implementing SSG: Initial Tasks
Feature Information for Implementing SSG
Table 3
Feature Information for Implementing SSG: Initial Tasks (continued)
Feature Name
Releases
Feature Configuration Information
SSG Port-Bundle Host-Key
12.3(4)B
12.2(11)T
12.3T
12.4
The SSG Port-Bundle Host Key feature enhances
communication and functionality between the Service
Selection Gateway (SSG) and the Cisco Subscriber Edge
Services Manager (SESM) by introducing a mechanism that
uses the host source IP address and source port to identify
and monitor subscribers.
The following sections provide information about this
feature:
SSG Unconfig
12.2T
12.3(4)T
•
Configuring SSG Port-Bundle Host-Key Functionality,
page 11
•
Configuring SSG to AAA Server Interaction, page 17
The SSG Unconfig feature releases and cleans up system
resources acquired by SSG.
The following section provides information about this
feature:
•
System Resource Cleanup When SSG Is Unconfigured,
page 3
The following command was introduced by this feature: no
ssg enable force-cleanup.
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
26
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.
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 SSG RADIUS Proxy” section on page 35.
Contents
•
Prerequisites for SSG RADIUS Proxy, page 2
•
Restrictions for SSG RADIUS Proxy, page 2
•
Information About SSG Authentication Using RADIUS Proxy, page 2
•
How to Configure SSG RADIUS Proxy, page 4
•
Configuration Examples for SSG Authentication of RADIUS Proxy Subscribers, page 29
•
Where to Go Next, page 34
•
Additional References, page 34
•
Feature Information for SSG RADIUS Proxy, page 35
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Configuring SSG to Serve as a RADIUS Proxy
Prerequisites for SSG RADIUS Proxy
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.
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 2
•
RADIUS Server Redundancy, page 3
•
Broadcast of Host Accounting, page 3
•
RADIUS Client Subnet Definition, page 3
•
Host Route Insertion, page 3
•
Types of Deployments that Use SSG RADIUS Proxy, page 4
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.
2
Configuring SSG to Serve as a RADIUS Proxy
Information About SSG Authentication Using RADIUS Proxy
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
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.
3
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
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.
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
How to Configure SSG RADIUS Proxy
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 4 (required)
•
Configuring SSG RADIUS Proxy for GPRS Networks, page 11 (optional)
•
Configuring SSG RADIUS Proxy for CDMA2000 Deployments, page 13 (optional)
•
Configuring SSG RADIUS Proxy for 802.1x WLAN Deployments, page 20 (optional)
•
Monitoring and Maintaining SSG RADIUS Proxy, page 25 (optional)
•
Troubleshooting SSG RADIUS Proxy, page 27 (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 4 (required)
•
Configuring Session Identification Attributes, page 6 (optional)
•
Configuring Timers for RADIUS Proxy, page 7(optional)
•
Configuring Multiple RADIUS Server Support, page 9 (optional)
Enabling SSG Autologon Using RADIUS Proxy
Perform this task to enable SSG Autologon using RADIUS Proxy.
4
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
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
Command or Action
Purpose
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
port.
•
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.
Example:
Router(config-radius-proxy)# server-port auth 23
acct 45
Step 3
Step 4
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.
forward accounting-start-stop [server-group
group-name]
Example:
Router(config-radius-proxy)# forward
accounting-start-stop
(Optional) Proxies accounting start/stop/update
packets generated by any RADIUS clients to the
AAA server.
•
server-group group-name—Configures SSG to
proxy RADIUS accounting packets to a specific
server group.
5
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
Step 5
Command or Action
Purpose
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
Returns to privileged EXEC mode.
end
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
Command or Action
Purpose
ssg radius-proxy
Enables SSG RADIUS Proxy and enters SSG-RADIUS-Proxy
mode.
Example:
Router(config)# ssg radius-proxy
Step 2
client-address ip-address
Example:
Configures the RADIUS-client to proxy requests from the
specified IP address to the RADIUS server and enters
SSG-RADIUS-Proxy-Client mode.
Router(config-radius-proxy)#
client-address 1.2.3.6
Step 3
key secret
Example:
Router(config-radproxy-client)# key
mypassword
6
(Optional) Configures the shared secret between SSG and the
RADIUS client. The secret attribute describes the shared secret.
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
Step 4
Step 5
Command or Action
Purpose
session-identifier {auto | msid |
correlation-id | accounting-session-id |
ip | username}
(Optional) Overrides SSG’s automatic RADIUS client session
identification.
•
auto—Automatically determines the session identifier.
Example:
•
msid—Uses the MSID as the client session identifier.
Router(config-radproxy-client)#
session-identifier auto
•
correlation-id—Uses the Correlation-ID as the session
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.
remove vsa {3gpp2 | cisco}
Example:
Router(config-radproxy-client)# remove
vsa 3gpp2
(Optional) Removes a VSA for a RADIUS client.
•
3gpp2—Removes all 3GPP2 VSAs.
•
cisco—Removes all Cisco VSAs.
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
7
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
DETAILED STEPS
Step 1
Command or Action
Purpose
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]
Example:
Router(config-radius-proxy)# server-port
[auth 1645][acct 1646]
Step 3
timeouts
Configures the authentication and accounting ports.
•
auth—(Optional) Configures the authentication port.
•
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.
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}]
Example:
Configures a host object timeout value. Valid range is 30 to
65536 seconds.
•
reset-mode—Specifies the type of traffic that resets
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.
Router(config-radproxy-timer)# idle 150
Step 6
session timeout
Example:
Configures the global session timeout for RADIUS proxy
sessions. Valid range is from 30 to 65535. There is no
default value.
Router(config-radproxy-timer)# session 100
Step 7
ip-address timeout
Example:
Router(config-radproxy-timer)# ip-address 25
8
Configures an SSG RADIUS Proxy IP address timeout.
Valid range is 1 to 30 seconds.
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
Step 8
Command or Action
Purpose
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
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.
Router(config-radproxy-timer)# msid 4 retry 9
Step 9
unrouted timeout
Configures the RADIUS proxy unroutable IP address
timeout. Valid range is from 1 to 43200 seconds.
•
Example:
Router(config-radproxy-timer)# unrouted 600
This timer may be used when insertion of host routes
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
5.
aaa group server radius group-name
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
9
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
DETAILED STEPS
Step 1
Command or Action
Purpose
aaa group server radius group-name
Groups RADIUS server hosts into distinct lists and distinct
methods.
Example:
•
Router(config)# aaa group server radius
myservergroup1
Step 2
server ip-address
[auth auth-port][acct acct-port]
Example:
Router(config-sg-radius)# server 1.2.3.4
[auth 1645][acct 1646]
group-name—Character string used to name the group of
servers.
Configures the IP address of the RADIUS server for the group
server.
•
ip-address—IP address of the RADIUS server host.
•
auth auth-port—(Optional) Specifies the User Datagram
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
[auth auth-port][acct acct-port]
Configures the IP address of the second RADIUS server for the
group server.
Example:
Router(config-sg-radius)# server 1.2.3.5
[auth 1645][acct 1646]
Step 7
10
Repeat Step 6 to configure additional RADIUS servers.
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
Step 8
Command or Action
Purpose
exit
Exits server group RADIUS configuration mode.
Example:
Router(config-sg-radius)# exit
Step 9
aaa accounting network
ssg_broadcast_accounting start-stop
broadcast group group-name group
group-name
Example:
Enables AAA accounting of requested services for billing or
security purposes when you use RADIUS.
•
ssg_broadcast_accounting—Configures the broadcast
group.
•
start-stop—Sends a “start” accounting notice at the
beginning of a process and a “stop” accounting notice at the
end of a process. The “start” accounting record is sent in the
background. The requested user process begins regardless of
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.
Router(config)# aaa accounting network
ssg_broadcast_accounting start-stop
broadcast group myservergroup1 group
myservergroup2
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 11
•
Overview of SSG RADIUS Proxy in GPRS Networks, page 12
•
IP Addresses Assignment in GPRS Networks that Use SSG RADIUS Proxy, page 12
•
Support For Overlapped Host IP Addresses, page 12
•
Forwarding of Accounting Packets, page 13
•
Session Identification by IP address, page 13
•
Per-PDP Accounting in GPRS Networks that Use SSG RADIUS Proxy, page 13
Prerequisites
Before you configure RADIUS Proxy in GPRS networks, you must complete the steps in Enabling SSG
Autologon Using RADIUS Proxy, page 4.
11
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
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.
12
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
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:
•
Prerequisites, page 14
•
Restrictions, page 14
•
CDMA, page 15
•
SSG RADIUS Proxy for CDMA2000 Overview, page 15
•
SSG RADIUS Proxy for CDMA2000 for Simple IP, page 16
•
SSG RADIUS Proxy for CDMA2000 for Mobile IP, page 17
•
Dynamic Home Agent Assignment, page 17
•
Benefits of SSG RADIUS Proxy for CDMA2000, page 18
13
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
This section contains the following tasks:
•
Configuring Home Agent IP Addresses, page 18
•
Verifying SSG RADIUS Proxy for CDMA2000, page 19
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
•
Note
No RADIUS packets generated by the HA can contain the 3GPP2-Correlation-ID VSA.
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 14 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
14
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
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.
15
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
Figure 1
CDMA Network
AAA
Corporate
VPN
IP core
ISP
Mobile
station
BTS
BSC,
PCF
WAP/Content
gateway
PDSN/FA
HA
Radio Access Network (RAN)
75773
Access
network
SSG
Key to Figure 1
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
16
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
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.
17
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
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
Command or Action
Purpose
ssg proxy-radius
Enables SSG RADIUS Proxy and enters SSG-RADIUS-Proxy
mode.
Example:
Router(config)# ssg proxy-radius
18
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
Step 2
Command or Action
Purpose
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
ip-address]
Configures a domain for a Home Agent in a CDMA2000 network.
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:
Router# show ssg host 10.0.0.0
------------------------ 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;
19
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
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:
Router# show ssg host 10.0.0.101
------------------------ HostObject Content ----------------------Activated: TRUE
Interface:
User Name: user1
Host IP: 10.0.0.101
Msg IP: 0.0.0.0 (0)
Host DNS IP: 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
Maximum Session Timeout: 0 seconds
Host Idle Timeout: 60000 seconds
Class Attr: NONE
User policing disabled
User logged on since: *06:01:02.000 UTC Fri May 3 2002
User last activity at: *06:01:09.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;
Subscribed Services: internet-blue; iptv; games; distlearn; corporate; shop; banking;
vidconf;
Subscribed Service Groups: NONE
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:
•
Prerequisites, page 21
•
EAP Implementations Supported by SSG, page 21
•
SSG EAP Environment, page 21
•
EAP Transparency, page 22
•
Prevention of IP Address Reuse, page 23
•
User Reconnect After Logoff, page 23
Perform the following task to configure SSG RADIUS Proxy for 802.1x WLAN deployments:
•
20
Configuring SSG RADIUS Proxy for 802.1x Deployments, page 23
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
Prerequisites
The SSG EAP Transparency features operates in the environment described in the “SSG EAP
Environment” section on page 21. 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:
Note
•
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
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.
21
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
•
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.
22
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
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 23.
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}
23
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
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
Command or Action
Purpose
ssg radius-proxy
Enables SSG RADIUS Proxy and SSG-RADIUS-Proxy
configuration mode.
Example:
Router(config)# ssg radius-proxy
Step 2
client-address IP-address
Configures the RADIUS client IP address.
•
Example:
Router(config-radius-proxy)# client-address
123.123.123.123
Step 3
key secret
Configures the shared secret.
•
Example:
Router(config-radproxy-client)# key cisco
Step 4
session-identifier {auto | msid |
correlation-id | accounting-session-id}
Example:
Router(config-radproxy-client)#
session-identifier auto
Step 5
timeouts
Example:
Router(config-radproxy-client)# timeouts
24
Use this command to configure the AP as a RADIUS
client to proxy requests from the specified IP address to
the RADIUS server.
Use the secret argument to configure each client IP with a
unique shared secret. This shared secret should be the
same one that is configured on the RADIUS client.
(Optional) Overrides SSG automatic RADIUS client
session identification. Keywords are as follows:
•
auto—Automatically determines the session identifier.
•
msid—Uses the MSID as the client session identifier.
•
correlation-id—Uses the Correlation-ID as the session
identifier.
•
accounting-session-id—Uses the
Accounting-Session-ID as a session identifier.
(Optional) Enters SSG-RADIUS-Proxy-Timeouts mode.
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
Step 6
Command or Action
Purpose
idle timeout
(Optional) Specifies a timeout value. Use one of two
commands:
or
ip-address timeout
Example:
Router(config-radproxy-timer)# idle 30
Step 7
•
The first command configures a host object timeout
value. The valid range is from 30 to 65536 seconds.
•
The second command configures an SSG RADIUS
Proxy IP address timeout. The valid range is from 1 to
180 seconds.
Exits to SSG-RADIUS-Proxy-Client configuration mode.
exit
Example:
Router(config-radproxy-timer)# exit
Step 8
Exits to SSG-RADIUS-Proxy configuration mode.
exit
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
25
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
DETAILED STEPS
Step 1
Command or Action
Purpose
clear ssg radius-proxy client-address ip address
(Optional) Clears all hosts connected to a specific
RADIUS client.
Example:
•
Router# clear ssg radius-proxy client-address
172.16.0.0
Step 2
clear ssg radius-proxy nas-address ip address
Example:
(Optional) Clears all hosts connected to a specific
NAS client.
•
Router# clear ssg radius-proxy nas-address
172.16.0.0
Step 3
show ssg auto-domain exclude-profile
Example:
Router# show ssg auto-domain exclude-profile
Step 4
show ssg binding
Example:
ip-address—IP address of the RADIUS client to
clear.
ip-address—IP address of the NAS client to
clear.
Displays the contents of an Auto-domain exclusion
profile downloaded from the AAA server. Only
Auto-domain exclude entries entered via CLI are
displayed.
Displays service names that have been bound to
interfaces and the interfaces to which they have been
bound.
Router# show ssg binding
Step 5
show ssg connection ip-address service-name
Example:
Displays the connections of a given host and service
name.
•
ip-address—IP address of an active SSG
connection. This is always a subscribed host.
•
service-name—The name of an active SSG
connection.
Router# show ssg connection 19.1.1.19 InstMsg
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]
Example:
Router# show ssg host 10.3.1.1
26
Displays the information about a subscriber and the
current connections of the subscriber.
•
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.
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
Step 8
Command or Action
Purpose
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
[domain domain-name] [free | inuse]
Displays IP address pool usage for a specific domain
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
1.
debug ssg port-map events
2.
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
Access-request:
3d05h:SSG-CTL-PAK:Received Packet:
sIP=5.5.5.2 sPort=1645 dIP=5.5.5.1 dPort=1645
27
Configuring SSG to Serve as a RADIUS Proxy
How to Configure SSG RADIUS Proxy
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
3d05h:RADIUS: Service-Type
[6]
6
Framed
[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
3d05h:RADIUS: Service-Type
[6]
6
Framed
[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
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.
28
Configuring SSG to Serve as a RADIUS Proxy
Configuration Examples for SSG Authentication of RADIUS Proxy Subscribers
Configuration Examples for SSG Authentication of RADIUS
Proxy Subscribers
This section contains the following examples:
•
SSG Autologon Using RADIUS Proxy: Examples, page 29
•
SSG RADIUS Proxy for CDMA2000: Examples, page 30
•
SSG RADIUS Proxy for 802.1x WLAN Deployments: Example, page 33
SSG Autologon Using RADIUS Proxy: Examples
This section contains the following examples:
•
Enabling SSG AutoLogon Using RADIUS Proxy: Example, page 29
•
Configuring Session Identification Attributes: Examples, page 29
•
Configuring Timers for RADIUS Proxy: Examples, page 30
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
client-address 172.16.0.0
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:
29
Configuring SSG to Serve as a RADIUS Proxy
Configuration Examples for SSG Authentication of RADIUS Proxy Subscribers
ssg enable
ssg proxy-radius
client-address 172.16.0.0
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
client-address 172.16.0.0
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
server-port auth 1812 acct 1813
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
server-port auth 1812 acct 1813
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
server-port auth 1812 acct 1813
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
server-port auth 1812 acct 1813
msid 3 retry 3
SSG RADIUS Proxy for CDMA2000: Examples
30
•
Configuring Multiple RADIUS Server Support: Example, page 31
•
Configuring Timers for RADIUS Proxy: Examples, page 30
•
Configuring Multiple RADIUS Server Support: Example, page 31
•
Configuring Home Agent IP Addresses: Example, page 31
•
Removing VSA Types: Examples, page 31
•
SSG RADIUS Proxy for CDMA2000 - Complete Configuration: Example, page 31
Configuring SSG to Serve as a RADIUS Proxy
Configuration Examples for SSG Authentication of RADIUS Proxy Subscribers
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
server 10.0.0.2 auth-port 1813 acct-port 1813
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
client-address 172.16.0.0
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
client-address 172.16.0.0
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:
!
version 12.3
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname host1
!
aaa new-model
31
Configuring SSG to Serve as a RADIUS Proxy
Configuration Examples for SSG Authentication of RADIUS Proxy Subscribers
!
aaa group server radius OPERATIONS
server 10.10.50.181 auth-port 1645 acct-port 1646
!
aaa group server radius RASCUSTOMER
server 10.10.50.180 auth-port 1645 acct-port 1646
!
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 authorization network ssg_aaa_author_internal_list 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 default-network 10.0.48.0 255.255.255.0
ssg service-password servicecisco
ssg radius-helper auth-port 1812 acct-port 1813
ssg radius-helper key cisco
ssg maxservice 12
ssg accounting interval 300000
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
32
Configuring SSG to Serve as a RADIUS Proxy
Configuration Examples for SSG Authentication of RADIUS Proxy Subscribers
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
server-port auth 1645 acct 1646
client-address 10.0.48.3
key cisco
!
client-address 10.0.48.4
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 retransmit 3
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 key troy
radius-server vsa send accounting
radius-server vsa send authentication
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
!
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.
.
.
.
radius-server host 9.2.36.253 auth-port 1645 acct-port 1646 key cisco
33
Configuring SSG to Serve as a RADIUS Proxy
Where to Go Next
ssg enable
ssg radius-proxy
server-port auth 1645 acct 1646
client-address 1.1.1.1
key cisco
session-identifier auto
!
client-address 1.1.1.1
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
Additional References
The following sections provide references related to configuring SSG to authenticate RADIUS Proxy
subscribers.
34
Configuring SSG to Serve as a RADIUS Proxy
Feature Information for SSG RADIUS Proxy
Related Documents
Related Topic
Document Title
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
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
Configuration Guide, Release 12.4
DHCP accounting
DHCP Accounting feature module for Cisco IOS Release 12.2(15)T
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,
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.
http://www.cisco.com/public/support/tac/home.shtml
Feature Information for SSG RADIUS Proxy
Table 1 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 later appear in the table.
Not all commands may be available in your Cisco IOS software release. For details on when support for
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.”
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.
35
Configuring SSG to Serve as a RADIUS Proxy
Feature Information for SSG RADIUS Proxy
Note
Table 1
Table 1 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.
Feature Information for Configuring SSG to Serve as a RADIUS Proxy
Feature Name
Releases
Feature Configuration Information
SSG AAA Server Group for Proxy RADIUS
12.3(3)B
12.3(1a)BW
12.3(4)T
12.4
This feature allows you to configure multiple AAA servers.
You can configure each remote RADIUS server with
timeout and retransmission parameters. SSG will perform
failover among the servers in the predefined group.
The following section provides information about this
feature:
•
SSG Autologon Using Proxy RADIUS
12.2(4)B
12.2(13)T
12.4
Configuring Multiple RADIUS Server Support, page 9
The SSG AutoLogon Using Proxy RADIUS feature enables
SSG to act as a RADIUS proxy for non-SSD clients whose
Access-Requests do not contain VSAs.
The following sections provide information about this
feature:
36
•
SSG AutoLogon Using RADIUS Proxy, page 2
•
Types of Deployments that Use SSG RADIUS Proxy,
page 4
•
Configuring SSG Autologon Using RADIUS Proxy,
page 4
•
Monitoring and Maintaining SSG RADIUS Proxy,
page 25
•
Troubleshooting SSG RADIUS Proxy, page 27
Configuring SSG to Serve as a RADIUS Proxy
Feature Information for SSG RADIUS Proxy
Table 1
Feature Information for Configuring SSG to Serve as a RADIUS Proxy
Feature Name
Releases
Feature Configuration Information
SSG EAP Transparency
12.2T
12.3(4)T
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.
The following sections provide information about this
feature:
SSG Proxy for CDMA2000
12.2(15)B
12.2T
12.3(4)T
•
Configuring SSG RADIUS Proxy for 802.1x WLAN
Deployments, page 20
•
EAP Implementations Supported by SSG, page 21
•
SSG EAP Environment, page 21
•
EAP Transparency, page 22
•
Prevention of IP Address Reuse, page 23
•
User Reconnect After Logoff, page 23
•
SSG Autologon Using RADIUS Proxy: Examples,
page 29
•
SSG RADIUS Proxy for 802.1x WLAN Deployments:
Example, page 33
This feature enables service selection in CDMA2000
networks through enhancements to the SSG RADIUS Proxy
functionality.
The following sections provide information about this
feature:
•
Configuring SSG RADIUS Proxy for CDMA2000
Deployments, page 13
•
Configuring Home Agent IP Addresses: Example,
page 31
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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
37
Configuring SSG to Serve as a RADIUS Proxy
Feature Information for SSG RADIUS Proxy
coincidental.
© 2007 Cisco Systems, Inc. All rights reserved.
38
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
This module was first published on May 2, 2005, and last updated on February 16, 2007.
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 Configuring SSG to Authenticate Web Logon
Subscribers” section on page 9.
Contents
•
Prerequisites for Configuring SSG to Authenticate Web Logon Subscribers, page 2
•
Restrictions for Configuring SSG to Authenticate Web Logon Subscribers, page 2
•
Information About Web Logon Subscribers, page 2
•
How to Configure SSG to Authenticate Web Logon Subscribers, page 4
•
Where to Go Next, page 8
•
Additional References, page 8
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Configuring SSG to Authenticate Web Logon Subscribers
Prerequisites for Configuring SSG to Authenticate Web Logon Subscribers
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.
•
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.
•
In the event of a server failure, SSG ignores configured server group group-name commands and,
instead, will failover to the server that is specified by the next radius-server host command in the
configuration; no matter how these servers are partitioned into groups by server group group-name
command(s).
For more information about the radius-server host command, see the Cisco IOS Security
Configuration Guide, Release 12.4. Refer to Configuring Authorization in the Part 1:
Authentication, Authorization, and Accounting (AAA) section.
Information About Web Logon Subscribers
Before you configure SSG authentication of web logon subscribers, you should understand the following
concepts:
•
Web Logon, page 2
•
TCP Redirection of Unauthenticated Users, page 3
•
SSG 3-Key Authentication, page 4
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.
2
Configuring SSG to Authenticate Web Logon Subscribers
Information About Web Logon Subscribers
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.
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 Subscriber Experience
Features module.
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.
3
Configuring SSG to Authenticate Web Logon Subscribers
How to Configure SSG to Authenticate Web Logon Subscribers
•
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.
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.
How to Configure SSG to Authenticate Web Logon Subscribers
The following sections describe how to configure SSG to authenticate web logon subscribers:
•
Configuring TCP Redirection for Unauthenticated Subscribers, page 4
•
Troubleshooting SSG TCP Redirection for Unauthenticated Subscribers, page 5
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
4
1.
ssg tcp-redirect
2.
server-group group-name
3.
server ip-address port
4.
exit
5.
redirect unauthenticated-user to group-name
Configuring SSG to Authenticate Web Logon Subscribers
How to Configure SSG to Authenticate Web Logon Subscribers
DETAILED STEPS
Step 1
Command or Action
Purpose
ssg tcp-redirect
Enables SSG TCP redirect.
Example:
Router(config)# ssg tcp-redirect
Step 2
server-group group-name
Example:
Router(config-ssg-redirect)# server-group
RedirectServer
Step 3
server ip-address port
Defines the group of one or more servers that make up
a named captive portal group and enables
ssg-redirect-group configuration mode.
•
Adds a server to a captive portal group.
•
ip-address—IP address of the server to add to the
captive portal group.
•
port—TCP port of the server to add to the captive
portal group.
Example:
Router(config-ssg-redirect-group)# server 10.0.0.0
8080
Step 4
group-name—Name of the captive portal group.
Exits ssg-redirect-group configuration mode.
exit
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}
5
Configuring SSG to Authenticate Web Logon Subscribers
How to Configure SSG to Authenticate Web Logon Subscribers
DETAILED STEPS
Step 1
Command or Action
Purpose
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
Step 2
show tcp-redirect mappings [host-ip-address
[interface]]
•
Displays the redirect mappings currently stored in
SSG.
•
If the host ip-address is provided, this command
displays detailed redirect mapping information
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.
Example:
Router# show tcp-redirect mappings 172.16.0.0
Step 3
show ssg host [ip-address]
Example:
Router# show ssg host 10.3.1.1
6
If the group-name is specified, this command
displays detailed information about that captive
portal group.
Displays information about a subscriber and current
connections of the subscriber.
Configuring SSG to Authenticate Web Logon Subscribers
Configuration Examples for SSG Authentication for Web Logon Subscribers
Step 4
Command or Action
Purpose
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
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.
Router# debug ssg tcp-redirect {packet | error |
event}
Step 5
debug ssg {ctrl-event | ctrl-error | ctrl-packets |
event | error}
Use this command to turn on debug information for
SSG.
•
ctrl-event — Displays all event messages for
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.
Example:
Router# debug ssg ctrl-packets
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
aaa authorization network default group radius
!
! enable SSG on the router
ssg enable
ssg radius-helper auth-port 1645 acct-port 1646
ssg radius-helper key cisco
!
! 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
7
Configuring SSG to Authenticate Web Logon Subscribers
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
ssg direction downlink
!
! 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 other methods of subscriber authentication, refer to the following modules:
•
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
To configure SSG to authenticate RADIUS Proxy subscribers, refer to Configuring SSG to Serve as a
RADIUS Proxy
Additional References
The following sections provide references related to configuring SSG to authenticate web logon
subscribers.
8
Configuring SSG to Authenticate Web Logon Subscribers
Feature Information for Configuring SSG to Authenticate Web Logon Subscribers
Related Documents
Related Topic
Document Title
SSG commands
Cisco IOS Service Selection Gateway Command Reference,
Release 12.4
Configuring SESM
Cisco Subscriber Edge Services Manager documentation.
RADIUS commands
Cisco IOS Security Command Reference, Release 12.4
RADIUS configuration tasks
Cisco IOS Security Configuration Guide, Release 12.4
Technical Assistance
Description
Link
Technical Assistance Center (TAC) home page,
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.
http://www.cisco.com/public/support/tac/home.shtml
Feature Information for Configuring SSG to Authenticate Web
Logon Subscribers
Table 3 lists the features in this module and provides links to specific configuration information. Only
features that were introduced or modified in Cisco IOS Release 12.2(1) or a later release appear in the
table.
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.
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.
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.
9
Configuring SSG to Authenticate Web Logon Subscribers
Feature Information for Configuring SSG to Authenticate Web Logon Subscribers
Table 3
Feature Information for Configuring SSG to Authenticate Web Logon Subscribers
Feature Name
Releases
Feature Configuration Information
SSG TCP Redirect
12.1(5)DC
12.2(4)B
12.2(8)T
12.3T
12.4
The SSG TCP Redirect feature forces subscribers to
authenticate before accessing the network or specific
services, and ensures that subscribers are only allowed to
access services authorized by the service provider.
The following sections provide information about this
feature:
•
TCP Redirection of Unauthenticated Users, page 3
•
SSG 3-Key Authentication, page 4
•
Configuring TCP Redirection for Unauthenticated
Subscribers, page 4
The following commands were introduced by this feature:
ssg tcp-redirect, redirect unauthenticated-user to.
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
10
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
This module was first published on May 2, 2005, and last updated on February 16, 2007.
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 Configuring SSG to Authenticate PPP Subscribers”
section on page 12.
Contents
•
Prerequisites, page 1
•
Restrictions, page 2
•
Information About SSG Authentication of PPP Subscribers, page 2
•
How to Configure SSG to Authenticate PPP Subscribers, page 4
•
Where to Go Next, page 11
•
Additional References, page 11
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.
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Configuring SSG to Authenticate PPP Subscribers
Restrictions
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.
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.
•
In the event of a server failure, SSG ignores configured server group group-name commands and,
instead, will failover to the server that is specified by the next radius-server host command in the
configuration; no matter how these servers are partitioned into groups by server group group-name
command(s).
For more information about the radius-server host command, see the Cisco IOS Security
Configuration Guide, Release 12.4. Refer to Configuring Authorization in the Part 1:
Authentication, Authorization, and Accounting (AAA) section.
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 2
•
PPP Termination Aggregation (PTA), page 3
•
PTA-Multidomain, page 3
•
PTA-MD Exclusion Lists, page 3
•
Single Signon for PPP Subscribers, page 4
•
VPI/VCI Indexing to Service Profiles, page 4
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:
•
2
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 interfaces
Configuring SSG to Authenticate PPP Subscribers
Information About SSG Authentication of PPP Subscribers
•
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 “[email protected]”). The structured username may be used in the following situations:
•
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, [email protected]). 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).
3
Configuring SSG to Authenticate PPP Subscribers
How to Configure SSG to Authenticate PPP Subscribers
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.
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.
How to Configure SSG to Authenticate PPP Subscribers
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 4 (required)
•
Configuring a PTA-MD Exclusion List, page 5 (optional)
•
Configuring VPI/VCI Indexing to Services, page 6 (optional)
•
Configuring Single Signon for PPP Subscribers, page 7 (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 2, 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
4
Configuring SSG to Authenticate PPP Subscribers
How to Configure SSG to Authenticate PPP Subscribers
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
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.
•
Example:
A downlink interface is an interface to
subscribers.
ssg direction downlink
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
(Optional) Creates a virtual-access interface only if
the inbound connection requires one.
virtual-profile
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
Configuring SSG to Authenticate PPP Subscribers
How to Configure SSG to Authenticate PPP Subscribers
5.
show ssg multidomain ppp exclude-list
DETAILED STEPS
Step 1
Command or Action
Purpose
ssg multidomain ppp
Enters SSG PTA-MD configuration mode.
Example:
Router(config)# ssg multidomain ppp
Step 2
exclude {domain name | all-domains}
Example:
Router(config-ssg-ppp-md)# exclude domain xyz
Step 3
download exclude-profile profile-name [password]
Example:
Adds names to the PTA-MD exclusion list.
•
domain—Adds a domain to the exclusion list.
•
name—Name of the domain to be added to the
exclusion list.
•
all-domains—Excludes all domains; in other
words, disables parsing of PPP structured
usernames.
Downloads the specified exclusion list from the AAA
server.
•
profile-name—Specifies the name for a list of
excluded names that may be downloaded from
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.
Router(config-ssg-ppp-md)# download exclude-profile
abc cisco
Step 4
(Optional) Returns to privileged EXEC mode.
end
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.
6
ssg vc-service-map service-name [interface interface-number] start-vpi | start-vpi/vci [end-vpi |
end-vpi/vci] exclusive | non-exclusive
Configuring SSG to Authenticate PPP Subscribers
How to Configure SSG to Authenticate PPP Subscribers
2.
exit
3.
show ssg vc-service-map
DETAILED STEPS
Step 1
Command or Action
Purpose
ssg vc-service-map service-name [interface
interface-number] start-vpi | start-vpi/vci
[end-vpi | end-vpi/vci] exclusive |
non-exclusive
Maps VCs to service names.
Example:
Router(config)# ssg vc-service-map Worldwide
3/33 exclusive
Step 2
•
The exclusive keyword means that the user has to use
the service specified.
•
The non-exclusive keyword means that the user may
optionally choose to override the configuration by
using a structured username with a different domain.
(Optional) Returns to global configuration mode.
exit
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
Command or Action
Purpose
ssg profile-cache
Enables the caching of user profiles for non-PPP
users.
Example:
Router(config)# ssg profile-cache
7
Configuring SSG to Authenticate PPP Subscribers
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 8
•
Disabling Parsing of PPP Structured Usernames: Example, page 9
•
Service-Name-to-VC Mapping: Example, page 9
•
Configuring the Virtual Template to Support PPP Subscribers: Example, page 9
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
8
Configuring SSG to Authenticate PPP Subscribers
Configuration Examples for SSG Authentication of PPP Subscribers
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
ssg direction downlink
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 9
•
PPPoEoA Users: Example, page 10
•
PPPoEoE Users: Example, page 11
PPPoA Users: Example
Configure AAA authentication through the RADIUS mechanism.
aaa authentication ppp default group radius
aaa authorization network default group radius
radius-server host 10.76.86.90 auth-port 1812 acct-port 1813 key cisco
radius-server vsa send accounting
radius-server vsa send authentication
Configure the PPP IP address on aggregation side
interface Loopback1
ip address 21.6.6.1 255.255.255.0
Configure the IP address pool if SSG is going to assign IP addresses.
9
Configuring SSG to Authenticate PPP Subscribers
Configuration Examples for SSG Authentication of PPP Subscribers
ip local pool ppp-pool 21.9.9.2 21.9.9.10
Configure the virtual template.
interface Virtual-Template1
description "PPP virtual-template for PPP host"
ip unnumbered Loopback1
peer default ip address pool ppp-pool
ppp authentication pap chap
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 AAA authentication through the RADIUS mechanism.
aaa authentication ppp default group radius
aaa authorization network default group radius
radius-server host 10.76.86.90 auth-port 1812 acct-port 1813 key cisco
radius-server vsa send accounting
radius-server vsa send authentication
Configure the PPP IP address on aggregation side.
interface Loopback1
ip address 21.6.6.1 255.255.255.0
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 PPPoE server using a VPDN group.
vpdn enable
vpdn-group 3
accept-dialin
protocol pppoe
virtual-template 1
Configure the virtual template.
interface Virtual-Template1
description "PPP virtual-template for PPP host"
ip unnumbered Loopback1
peer default ip address pool ppp-pool
ppp authentication pap chap
Configure the ATM interface on which the PPPoEoA user comes in.
interface ATM4/0.23 point-to-point
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
10
Configuring SSG to Authenticate PPP Subscribers
Where to Go Next
PPPoEoE Users: Example
Configure AAA authentication through the RADIUS mechanism.
aaa authentication ppp default group radius
aaa authorization network default group radius
radius-server host 10.76.86.90 auth-port 1812 acct-port 1813 key cisco
radius-server vsa send accounting
radius-server vsa send authentication
Configure the PPP IP address on aggregation side.
interface Loopback1
ip address 21.6.6.1 255.255.255.0
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 PPPoE server using a VPDN group.
vpdn enable
vpdn-group 3
accept-dialin
protocol pppoe
virtual-template 1
Configure the virtual template.
interface Virtual-Template1
description "PPP virtual-template for PPP host"
ip unnumbered Loopback1
peer default ip address pool ppp-pool
ppp authentication pap chap
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
To configure other methods of subscriber authentication, refer to the following modules:
•
Configuring SSG to Authenticate Web Logon Subscribers
•
Configuring SSG to Authenticate Subscribers with Transparent Autologon
•
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
•
Configuring SSG Support for Subnet-Based Authentication
•
Configuring SSG for MAC-Address-Based Authentication
Additional References
The following sections provide references related to configuring SSG to authenticate PPP subscribers.
11
Configuring SSG to Authenticate PPP Subscribers
Feature Information for Configuring SSG to Authenticate PPP Subscribers
Related Documents
Related Topic
Document Title
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
Configuration Guide, Release 12.4
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,
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.
http://www.cisco.com/public/support/tac/home.shtml
Feature Information for Configuring SSG to Authenticate PPP
Subscribers
Table 3 lists the features in this module and provides links to specific configuration information. Only
features that were introduced or modified in Cisco IOS Release 12.2(1) or a later release appear in the
table.
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.
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.
Note
12
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.
Configuring SSG to Authenticate PPP Subscribers
Feature Information for Configuring SSG to Authenticate PPP Subscribers
Table 3
Feature Information for Configuring SSG to Authenticate PPP Subscribers
Feature Name
Releases
Feature Configuration Information
PPP Subscriber Access
12.2(16)B
12.3(4)T
12.4
The PPP subscriber access feature supports PPP as a
subscriber access protocol.
The following sections provide information about this
feature:
•
PPP Subscriber Access, page 2
•
PPP Termination Aggregation (PTA), page 3
•
Configuring SSG Support for PPP Subscribers, page 4
•
Configuring Single Signon for PPP Subscribers, page 7
•
Configuring the Virtual Template to Support PPP
Subscribers: Example, page 9
•
Basic PPPoA and PPPoE Configuration: Examples,
page 9
The following commands were introduced by this feature:
ssg direction downlink.
PTA-MD Exclusion List
12.2(15)B
12.3(4)T
12.4
The PTA-MD Exclusion List feature allows you to create a
set of domains that are excluded from normal SSG
structured username processing.
The following sections provide information about this
feature:
•
PTA-Multidomain, page 3
•
PTA-MD Exclusion Lists, page 3
•
Configuring a PTA-MD Exclusion List, page 5
•
Adding Domains to an Existing PTA-MD Exclusion
List: Examples, page 8
The following commands were introduced by this feature:
download exclude-profile (PTA-MD), exclude
(PTA-MD), show ssg multidomain, ppp exclude-list, ssg
multidomain ppp.
13
Configuring SSG to Authenticate PPP Subscribers
Feature Information for Configuring SSG to Authenticate PPP Subscribers
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
14
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
This module was first published on May 2, 2005, and last updated on February 16, 2007.
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 Configuring SSG to Authenticate Subscribers with
Transparent Autologon” section on page 15.
Contents
•
Prerequisites for SSG Transparent Autologon, page 1
•
Restrictions for SSG Transparent Autologon, page 2
•
Information About SSG Transparent Autologon, page 2
•
How to Configure SSG Transparent Autologon, page 6
•
Configuration Examples for SSG Transparent Autologon, page 13
•
Where to Go Next, page 14
•
Additional References, page 14
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.
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
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.
•
In the event of a server failure, SSG ignores configured server group group-name commands and,
instead, will failover to the server that is specified by the next radius-server host command in the
configuration; no matter how these servers are partitioned into groups by server group group-name
command(s).
For more information about the radius-server host command, see the Cisco IOS Security
Configuration Guide, Release 12.4. Refer to Configuring Authorization in the Part 1:
Authentication, Authorization, and Accounting (AAA) section.
Information About SSG Transparent Autologon
Before you configure this feature, you should understand the following concepts:
•
Overview of SSG Transparent Autologon, page 2
•
SSG Transparent Autologon User-to-Service Packet Flow, page 3
•
States of SSG Transparent Autologon Users, page 4
•
Switching Between TP and Host User States, page 6
•
Benefits of SSG Transparent Autologon, page 6
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:
2
•
User session with host.
•
User session without host (known as a transparent pass-through user, or TP).
Configuring SSG to Authenticate Subscribers with Transparent Autologon
Information About SSG Transparent Autologon
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.
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 4.
Figure 1 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:
3
Configuring SSG to Authenticate Subscribers with Transparent Autologon
Information About SSG Transparent Autologon
– 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.
Figure 1
User-to-Service Packet Flow
AAA
2
3
Radius
IP
4
1
SSG
98658
IP
States of SSG Transparent Autologon Users
The following sections describe the SSG transparent autologon user states:
•
User with Host, page 4
•
Transparent Pass-Through User (TP), page 5
•
User Waiting for Authorization (WA), page 5
•
Suspect User (SP), page 5
•
Unidentified User (NR), page 5
User with Host
When the SSG Transparent Autologon feature is configured, the host object user can be logged on in one
of three ways:
4
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.
Configuring SSG to Authenticate Subscribers with Transparent Autologon
Information About SSG Transparent Autologon
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.
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).
5
Configuring SSG to Authenticate Subscribers with Transparent Autologon
How to Configure SSG Transparent Autologon
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.
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.
How to Configure SSG Transparent Autologon
This section contains the following tasks:
•
Configuring SSG Transparent Autologon, page 6
•
Configuring the AAA Subscriber Profile for SSG Transparent Autologon Subscribers, page 8
•
Monitoring and Maintaining SSG Transparent Autologon, page 8
•
Troubleshooting SSG Transparent Autologon, page 11
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
6
Configuring SSG to Authenticate Subscribers with Transparent Autologon
How to Configure SSG Transparent Autologon
DETAILED STEPS
Step 1
Command or Action
Purpose
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
Example:
(Optional) Specifies the server group to be used for
authorization of SSG transparent autologon users.
•
If no server group is specified, SSG uses the default
server group for authorization. The default server group
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.
Router(config-login-transparent)# authorization
list list1
Step 3
authorization pending maximum number
Example:
(Optional) Specifies the maximum number of SSG TAL
access requests that can be pending.
•
Router(config-login-transparent)# authorization
pending maximum 1200
Step 4
authorization rate-limit number
Example:
(Optional) Specifies the number of SSG new TAL
authorization requests sent per second.
•
The rate must be based on the number of requests the
AAA server can handle per second.
•
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.
Router(config-login-transparent)# authorization
rate-limit 100
Step 5
packet drop during-authorization
Example:
When the number of access requests reaches the
configured limit, any packets that would cause SSG to
send a new RADIUS request are dropped at the CEF
path, and SSG generates a syslog message.
(Optional) Specifies that packets received from the user
during WA state (that is, during authrization) will be
dropped.
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
Example:
(Optional) Specifies the maximum length of time a suspect
user (SP) remains in the suspect user list.
•
The default timeout is 3600 seconds.
Router(config-login-transparent)# user suspect
timeout 600
7
Configuring SSG to Authenticate Subscribers with Transparent Autologon
How to Configure SSG Transparent Autologon
Step 8
Command or Action
Purpose
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
response from the AAA server to an authorization
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.
Router(config-login-transparent)# user
unidentified timeout 600
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
Step 10
(Optional) Returns to global configuration mode.
exit
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
8
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]
Configuring SSG to Authenticate Subscribers with Transparent Autologon
How to Configure SSG Transparent Autologon
10. clear ssg user transparent unidentified {all | ipaddress}
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router# enable
Step 2
show ssg user transparent
Example:
Displays all users (pass-through, suspect, unidentified, or
waiting for authorization) in a table of IP addresses and user
types.
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
[ipaddress | count]
Displays a list of transparent (TP) users.
Example:
Router# show ssg user transparent passthrough
Step 6
clear ssg user transparent passthrough {all |
ipaddress}
Deletes pass-through user entries.
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 |
ipaddress}
Deletes suspect (SP) user entries.
Example:
Router# clear ssg user transparent suspect all
9
Configuring SSG to Authenticate Subscribers with Transparent Autologon
How to Configure SSG Transparent Autologon
Step 9
Command or Action
Purpose
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 |
ipaddress}
Deletes users for whom there is no response from AAA to
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
10
Configuring SSG to Authenticate Subscribers with Transparent Autologon
How to Configure SSG Transparent Autologon
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
Command or Action
Purpose
debug ssg transparent login {errors | events}
[ipaddress]
Displays transparent logon control events or errors.
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
11
Configuring SSG to Authenticate Subscribers with Transparent Autologon
How to Configure SSG Transparent Autologon
*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.875:SSG-TAL-EVN:100.0.0.2:Added entry successfully
*Jan 15 12:40:39.875:SSG-TAL-EVN:100.0.0.2:Attempting authorization
*Jan 15 12:40:39.875:SSG-TAL-EVN:100.0.0.2:Attempting to send authorization request
*Jan 15 12:40:39.879:SSG-TAL-EVN:100.0.0.2:Authorization response received
*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.363:SSG-TAL-EVN:10.10.10.10:Added entry successfully
*Jan 15 12:43:25.363:SSG-TAL-EVN:10.10.10.10:Attempting authorization
*Jan 15 12:43:25.363:SSG-TAL-EVN:10.10.10.10:Attempting to send authorization request
*Jan 15 12:43:25.939:SSG-TAL-EVN:10.10.10.10:Authorization response received
*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 SP/NR timer
*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
*Jan 15 12:47:08.943:SSG-TAL-EVN:10.11.11.11:Entry removed
12
Configuring SSG to Authenticate Subscribers with Transparent Autologon
Configuration Examples for SSG Transparent Autologon
*Jan 15 12:47:08.943:SSG-TAL-EVN:10.11.11.11:Stop SP/NR timer
*Jan 15 12:47:08.943:SSG-TAL-EVN:10.11.11.11:Stop Idle timer
*Jan 15 12:47:08.943:SSG-TAL-EVN:10.11.11.11:Stop session timer
*Jan 15 12:47:08.943:SSG-TAL-EVN:10.0.0.2:Entry removed
*Jan 15 12:47:08.943:SSG-TAL-EVN:10.0.0.2:Stop SP/NR timer
*Jan 15 12:47:08.943:SSG-TAL-EVN:10.0.0.2:Stop Idle timer
*Jan 15 12:47:08.943:SSG-TAL-EVN:10.0.0.2:Stop session timer
Configuration Examples for SSG Transparent Autologon
This section provides the following configuration examples:
•
SSG Transparent Autologon Configuration: Example, page 13
•
AAA User Profile Configuration for Transparent Passthrough (TP) Users: Example, page 13
•
AAA User Profile Configuration for Users with Hosts: Example, page 14
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
server 23.0.0.100 auth-port 1646 acct-port 1646
!
! 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",
13
Configuring SSG to Authenticate Subscribers with Transparent Autologon
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 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
To configure SSG to authenticate RADIUS Proxy subscribers, refer to the Configuring SSG to Serve as
a RADIUS Proxy module.
Additional References
The following sections provide references related to configuring SSG to authenticate TAL subscribers.
14
Configuring SSG to Authenticate Subscribers with Transparent Autologon
Feature Information for Configuring SSG to Authenticate Subscribers with Transparent Autologon
Related Documents
Related Topic
Document Title
SSG commands
Cisco IOS Service Selection Gateway Command Reference,
Release 12.4
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
Configuration Guide, Release 12.4
Technical Assistance
Description
Link
Technical Assistance Center (TAC) home page,
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.
http://www.cisco.com/public/support/tac/home.shtml
Feature Information for Configuring SSG to Authenticate
Subscribers with Transparent Autologon
Table 1 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.
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.
Note
Table 1 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.
15
Configuring SSG to Authenticate Subscribers with Transparent Autologon
Feature Information for Configuring SSG to Authenticate Subscribers with Transparent Autologon
Table 1
Feature Information for Configuring SSG to Authenticate Subscribers with Transparent Autologon
Feature Name
Releases
Feature Configuration Information
SSG Transparent Autologon
12.3(1a)BW
12.3(3)B
12.3(7)T
12.4
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.
The following sections provide information about this
feature:
•
Overview of SSG Transparent Autologon, page 2
•
SSG Transparent Autologon User-to-Service Packet
Flow, page 3
•
States of SSG Transparent Autologon Users, page 4
•
Switching Between TP and Host User States, page 6
•
Benefits of SSG Transparent Autologon, page 6
•
Configuring SSG Transparent Autologon, page 6
•
Configuring the AAA Subscriber Profile for SSG
Transparent Autologon Subscribers, page 8
•
Monitoring and Maintaining SSG Transparent
Autologon, page 8
•
Troubleshooting SSG Transparent Autologon, page 11
The following commands were introduced by this feature:
clear ssg user transparent, show ssg user transparent,
ssg login transparent, .
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
16
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
This module was first published on May 2, 2005, and last updated on February 16, 2007.
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 Configuring SSG to Authenticate Subscribers
Automatically in the Service Domain” section on page 12.
Contents
•
Prerequisites for SSG AutoDomain, page 2
•
Restrictions for SSG AutoDomain, page 2
•
Information About SSG AutoDomain, page 2
•
How to Configure SSG AutoDomain, page 7
•
Configuration Examples for SSG AutoDomain, page 11
•
Where to Go Next, page 11
•
Additional References, page 12
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
Prerequisites for SSG AutoDomain
Prerequisites for SSG AutoDomain
Before you configure SSG AutoDomain, SSG must be enabled.
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).
•
In the event of a server failure, SSG ignores configured server group group-name commands and,
instead, will failover to the server that is specified by the next radius-server host command in the
configuration; no matter how these servers are partitioned into groups by server group group-name
command(s).
For more information about the radius-server host command, see the Cisco IOS Security
Configuration Guide, Release 12.4. Refer to Configuring Authorization in the Part 1:
Authentication, Authorization, and Accounting (AAA) section.
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 2
•
IP Address Assignment, page 3
•
SSG AutoDomain Basic and Extended Modes, page 4
•
SSG AutoDomain Service Types, page 4
•
Access Point Names, page 5
•
AutoDomain Name Selection, page 5
•
Multiple Local IP Pools, page 6
•
Primary AutoDomain Service Termination, page 6
•
SSG AutoDomain and NAT, page 6
•
Benefits of SSG AutoDomain, page 7
Overview of SSG AutoDomain
The SSG AutoDomain feature allows SSG to authenticate subscribers in the service domain.
2
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
Information About SSG AutoDomain
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 “[email protected]”, “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.
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.
3
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
Information About SSG AutoDomain
•
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.
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.
4
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
Information About SSG AutoDomain
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
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.
5
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
Information About SSG AutoDomain
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:
ssg radius-proxy
address-pool 1.1.1.1
address-pool 1.1.2.3
address-pool 1.1.3.4
address-pool 1.1.4.5
!
1.1.2.2
1.1.3.3
1.1.4.4 acme.com
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 1 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.
6
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
How to Configure SSG AutoDomain
Table 1
Service-Info Vendor-Specific Attribute
Attribute ID
Vendor ID
Subattribute
ID and Type
Attribute Name
Subattribute Data
26
9
251
NAT user address
C—Service-Info code for NAT
user address.
Service-Info
0 or 1—Disable or enable NAT
of user address respectively.
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.
How to Configure SSG AutoDomain
To configure SSG subscriber authentication for services, perform the following tasks:
•
Configuring SSG AutoDomain, page 7
•
Monitoring and Maintaining SSG AutoDomain, page 9
•
Troubleshooting SSG AutoDomain, page 10
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}
7
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
How to Configure SSG AutoDomain
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.
DETAILED STEPS
Step 1
Command or Action
Purpose
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
calling-station-id | nas-identifier | attribute
<number>}
Example:
Router(config-auto-domain)# select
calling-station-id
(Optional) Configures the AutoDomain selection method.
•
username—Configures the algorithm to use only the
domain portion of the username to select the
AutoDomain.
•
called-station-id—Configures the algorithm to use
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
Example:
Router(config-auto-domain)# exclude domain xyz
8
(Optional) Adds names to the AutoDomain exclusion list.
•
apn—Adds an APN to the exclusion list.
•
domain—Adds a domain to the exclusion list.
•
name—Name of the APN or domain to be added to the
exclusion list.
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
How to Configure SSG AutoDomain
Step 5
Command or Action
Purpose
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
names that may be downloaded from the AAA server.
•
password—Password for a list of excluded names that
may be downloaded from the AAA server.
Router(config-auto-domain)# download
exclude-profile abc cisco
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
Step 8
(Optional) Returns to privileged EXEC mode.
end
Example:
Router(config-auto-domain)# end
Step 9
Configure NAT in the service profile for the
AutoDomain service.
Defines a Service-Info attribute in the service profile for the
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
9
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
How to Configure SSG AutoDomain
DETAILED STEPS
Step 1
Command or Action
Purpose
clear ssg radius-proxy client-address ip-address
(Optional) Clears all hosts connected to a specific
RADIUS client.
•
Example:
ip-address—IP address of a 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).
•
Example:
ip-address—IP address of a RADIUS client.
Router# clear ssg radius-proxy nas-address
172.16.0.0
Step 3
show ssg auto-domain exclude-profile
(Optional) Displays the contents of an AutoDomain
exclusion profile downloaded from the AAA server.
•
Example:
Router# show ssg auto-domain exclude-profile
Step 4
show ssg binding
Example:
Only AutoDomain exclude entries entered via
CLI are displayed.
(Optional) Displays service names that have been
bound to interfaces and the interfaces to which they
have been bound.
Router# show ssg binding
Step 5
show ssg connection ip-address service-name
Example:
(Optional) Displays the connections of a given host
and service name.
•
ip-address—IP address of an active SSG
connection. This is always a subscribed host.
•
service-name—The name of an active SSG
connection.
Router# show ssg connection 19.1.1.19 InstMsg
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
10
1.
debug ssg ctrl-events
2.
debug ssg ctrl-errors
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
Configuration Examples for SSG AutoDomain
DETAILED STEPS
Step 1
Command or Action
Purpose
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 11
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 other methods of subscriber authentication, refer to the following modules:
•
Configuring SSG to Authenticate Web Logon Subscribers
•
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
To configure SSG to authenticate RADIUS Proxy subscribers, refer to Configuring SSG to Serve as a
RADIUS Proxy
11
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
Additional References
Additional References
The following sections provide references related to configuring SSG to authenticate subscribers for
services.
Related Documents
Related Topic
Document Title
Configuring SESM
Cisco Subscriber Edge Services Manager documentation.
Configuring L2TP
Cisco IOS Dial Technologies Configuration Guide, Release 12.4
Cisco IOS Dial Technologies Command Reference, Release 12.4
SSG commands
Cisco IOS Service Selection Gateway Command Reference,
Release 12.4
RADIUS commands
Cisco IOS Security Command Reference, Release 12.4
RADIUS configuration tasks
“Configuring RADIUS” chapter in the Cisco IOS Security
Configuration Guide, Release 12.4
Technical Assistance
Description
Link
Technical Assistance Center (TAC) home page,
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.
http://www.cisco.com/public/support/tac/home.shtml
Feature Information for Configuring SSG to Authenticate
Subscribers Automatically in the Service Domain
Table 2 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.
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.
12
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
Feature Information for Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
Note
Table 2
Table 2 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.
Feature Information for Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
Feature Name
Releases
Feature Configuration Information
SSG AutoDomain
12.2(4)B
12.2(13)T
12.4
The SSG AutoDomain feature allows Service Selection
Gateway (SSG) to authenticate subscribers automatically in
the service domain.
The following sections provide information about this
feature:
•
Overview of SSG AutoDomain, page 2
•
IP Address Assignment, page 3
•
SSG AutoDomain Basic and Extended Modes, page 4
•
SSG AutoDomain Service Types, page 4
•
Access Point Names, page 5
•
AutoDomain Name Selection, page 5
•
Multiple Local IP Pools, page 6
•
Primary AutoDomain Service Termination, page 6
•
SSG AutoDomain and NAT, page 6
•
Benefits of SSG AutoDomain, page 7
•
Configuring SSG AutoDomain, page 7
•
Monitoring and Maintaining SSG AutoDomain, page 9
•
Troubleshooting SSG AutoDomain, page 10
•
SSG AutoDomain: Example, page 11
The following commands were introduced by this feature:
exclude, mode extended, nat user-address, select, show
ssg auto-domain exclude-profile, ssg auto-domain
13
Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
Feature Information for Configuring SSG to Authenticate Subscribers Automatically in the Service Domain
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
14
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
This module was first published on May 2, 2005, and last updated on May 2, 2005.
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 SSG On-Demand IP Address Renewal, page 7.
Contents
•
Prerequisites for SSG On-Demand IP Address Renewal, page 1
•
Restrictions for SSG On-Demand IP Address Renewal, page 2
•
Information About SSG On-Demand IP Address Renewal, page 2
•
How to Configure SSG for On-Demand IP Address Renewal, page 4
•
Configuration Examples for SSG On-Demand IP Address Renewal, page 6
•
Command Reference, page 7
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.
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
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 2
•
DHCP Notification for SSG On-Demand IP Address Renewal, page 2
•
Benefits of SSG On-Demand IP Address Renewal, page 4
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 3.
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.
2
Configuring SSG for On-Demand IP Address Renewal
Information About SSG On-Demand IP Address Renewal
SSG On-Demand IP Address Renewal Packet Flow
Figure 1 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.
Simple On-Demand IP Address Renewal Network Topology
Subscriber's PC
SSG
DHCP module
DHCP server
127931
Figure 1
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:
3
Configuring SSG for On-Demand IP Address Renewal
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.
How to Configure SSG for On-Demand IP Address Renewal
This section contains the following tasks:
•
Configuring SSG On-Demand IP Address Renewal, page 4 (required)
•
Verifying and Troubleshooting SSG On-Demand IP Address Renewal, page 5 (optional)
Configuring SSG On-Demand IP Address Renewal
This task explains how to configure SSG for on-demand IP address renewal.
SUMMARY STEPS
4
1.
enable
2.
configure terminal
3.
ssg intercept dhcp
Configuring SSG for On-Demand IP Address Renewal
How to Configure SSG for On-Demand IP Address Renewal
DETAILED STEPS
Step 1
Command or Action
Purpose
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
ssg intercept dhcp
Example:
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.
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 5
•
Displaying Subscriber Login Events and Errors for the SSG On-Demand IP Address Renewal
Feature, page 6
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
5
Configuring SSG for On-Demand IP Address Renewal
Configuration Examples for SSG On-Demand IP Address Renewal
1:10.3.1.1
2:10.3.6.1
(active) Host name:pppoauser
(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
Enables privileged EXEC mode. Enter your password if prompted.
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:
•
6
Configuring SSG for On-Demand IP Address Renewal: Example, page 7
Configuring SSG for On-Demand IP Address Renewal
Command Reference
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
Command Reference
The following commands are introduced or modified in the feature or features documented in this
module. For information about these commands, see the Cisco IOS Service Selection Gateway Command
Reference at http://www.cisco.com/en/US/docs/ios/ssg/command/reference/ssg_book.html. For
information about all Cisco IOS commands, go to the Command Lookup Tool at
http://tools.cisco.com/Support/CLILookup or to the Cisco IOS Master Commands List.
•
Glossary
Feature Information for SSG On-Demand IP Address Renewal
Table 1 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.3(14)T 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.
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.
Note
Table 1 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.
7
Configuring SSG for On-Demand IP Address Renewal
Feature Information for SSG On-Demand IP Address Renewal
Table 1
Feature Information for SSG On-Demand IP Address Renewal
Feature Name
Releases
Feature Configuration Information
On-Demand IP Address Renewal for SSG
12.3(14)T
12.4
The SSG 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.
The following sections provide information about this
feature:
•
Overview of SSG On-Demand IP Address Renewal,
page 2
•
DHCP Notification for SSG On-Demand IP Address
Renewal, page 2
•
SSG On-Demand IP Address Renewal Packet Flow,
page 3
•
Benefits of SSG On-Demand IP Address Renewal,
page 4
•
Configuring SSG On-Demand IP Address Renewal,
page 4
•
Verifying and Troubleshooting SSG On-Demand IP
Address Renewal, page 5
•
Configuring SSG for On-Demand IP Address Renewal:
Example, page 7
The following commands were introduced or modified by
this feature: debug ssg dhcp, ssg intercept dhcp.
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
8
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
This module was first published on May 2, 2005, and last updated on May 2, 2005.
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 SSG Support for Subnet-Based Authentication”
section on page 4.
Contents
•
Prerequisites for SSG Support for Subnet-Based Authentication, page 1
•
Restrictions for SSG Support for Subnet-Based Authentication, page 2
•
Information About SSG Support for Subnet-Based Authentication, page 2
•
How to Configure SSG Support for Subnet-Based Authentication, page 2
•
Additional References, page 4
Prerequisites for SSG Support for Subnet-Based Authentication
SSG must be enabled before subnet-based authentication for SSG can be configured.
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Configuring SSG Support for Subnet-Based Authentication
Restrictions for SSG Support for Subnet-Based Authentication
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.
•
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 2
•
Benefits of SSG Support for Subnet-Based Authentication, page 2
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:
•
2
Verifying SSG Support for Subnet-Based Authentication, page 3 (optional)
Configuring SSG Support for Subnet-Based Authentication
How to Configure SSG Support for Subnet-Based Authentication
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.
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
Enables privileged EXEC mode. Enter your password if prompted.
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
------------------------ HostObject Content ----------------------Activated: TRUE
Interface:
User Name: user1
Host IP : 10.0.0.0
Mask : 255.255.255.0
Msg IP: 0.0.0.0 (0)
Host DNS IP: 0.0.0.0
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 2004
User last activity at: *05:59:52.000 UTC Fri May 3 2004
3
Configuring SSG Support for Subnet-Based Authentication
Additional References
SMTP Forwarding: NO
Initial TCP captivate: NO
TCP Advertisement captivate: NO
Default Service: NONE
DNS Default Service: NONE
Active Services: NONE
AutoService: NONE
Subscribed Services: passthru1; proxynat1; tunnel1; proxy1
Subscribed Service Groups: NONE
Additional References
The following sections provide references related to the SSG Support for Subnet-Based Authentication
feature.
Related Documents
Related Topic
Document Title
SSG commands
Cisco IOS Service Selection Gateway Command Reference,
Release 12.4
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
Configuration Guide, Release 12.4
Technical Assistance
Description
Link
Technical Assistance Center (TAC) home page,
containing 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.
http://www.cisco.com/public/support/tac/home.shtml
Feature Information for SSG Support for Subnet-Based
Authentication
Table 1 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.3(14)T 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.
4
Configuring SSG Support for Subnet-Based Authentication
Feature Information for SSG Support for Subnet-Based Authentication
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.
Note
Table 1
Table 1 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.
Feature Information for SSG Support for Subnet-Based Authentication
Feature Name
Releases
Feature Configuration Information
SSG Support for Subnet-Based Authentication
12.3(14)T
12.4
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.
The following sections provide information about this
feature:
•
Identifying Subnet-Based Subscribers, page 2
•
Benefits of SSG Support for Subnet-Based
Authentication, page 2
•
Verifying SSG Support for Subnet-Based
Authentication, page 3
The following commands were modified by this feature:
show ssg connection, show ssg host.
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
5
Configuring SSG Support for Subnet-Based Authentication
Feature Information for SSG Support for Subnet-Based Authentication
6
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
This module was first published on May 2, 2005, and last updated on May 2, 2005.
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 Configuring SSG for MAC-Address-Based
Authentication” section on page 9.
Contents
•
Prerequisites for MAC-Address-Based Authentication for SSG, page 1
•
Restrictions for MAC-Address-Based Authentication for SSG, page 2
•
Information About MAC-Address-Based Authentication for SSG, page 2
•
How to Configure MAC-Address-Based Authentication for SSG, page 6
•
Additional References, page 8
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.
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Configuring SSG for MAC-Address-Based Authentication
Restrictions for MAC-Address-Based Authentication for SSG
•
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.
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 2
•
Subscriber Login with MAC-Address-Based Authentication for SSG, page 2
•
Benefits of MAC-Address-Based Authentication for SSG, page 6
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 3. 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 5.
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
2
Configuring SSG for MAC-Address-Based Authentication
Information About MAC-Address-Based Authentication for SSG
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.
Figure 1 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.
Subscriber's PC
MAC-Address-Based Authentication for SSG Network Topology
L3 switch
DHCP relay agent
SSG
DHCP
server
(CNR)
SESM
(NWSP)
AAA
server
(RDP)
LDAP
127932
Figure 1
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.
3
Configuring SSG for MAC-Address-Based Authentication
Information About MAC-Address-Based Authentication for SSG
11. SSG redirects the subscriber’s HTTP session to SESM.
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.
– 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.
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:
– 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.
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.
– 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.
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.
4
Configuring SSG for MAC-Address-Based Authentication
Information About MAC-Address-Based Authentication for SSG
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.
– 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 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:
– 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.
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.
– 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.
5
Configuring SSG for MAC-Address-Based Authentication
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.
How to Configure MAC-Address-Based Authentication for SSG
This section contains the following tasks:
•
Configuring a DHCP Lease Query Request for MAC-Address-Based Authentication, page 6
(required)
•
Configuring an IP DHCP Lease Query Request, page 7 (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
2.
configure terminal
3.
ssg query mac dhcp
4.
username mac
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Example:
Router# configure terminal
6
Enters global configuration mode.
Configuring SSG for MAC-Address-Based Authentication
How to Configure MAC-Address-Based Authentication for SSG
Step 3
Command or Action
Purpose
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
Configures SSG to send a subscriber’s MAC address as the
username in TAL authorization requests.
username mac
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
2.
configure terminal
3.
ssg radius-proxy
4.
client-address ip-address [vrf vrf-name]
5.
query ip dhcp
DETAILED STEPS
Step 1
Command or Action
Purpose
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
ssg radius-proxy
Enables the SSG RADIUS proxy.
Example:
Router(config)# ssg radius proxy
7
Configuring SSG for MAC-Address-Based Authentication
Configuration Examples for SSG MAC-Address-Based Authentication
Step 4
Command or Action
Purpose
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
Enables DHCP lease query requests for a RADIUS proxy
client.
query ip dhcp
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 8
•
Configuring an IP DHCP Lease Query Request: Example, page 8
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
client-address 10.0.0.0
query ip dhcp
Additional References
The following sections provide references related to the MAC-Address-Based Authentication for SSG
feature.
8
Configuring SSG for MAC-Address-Based Authentication
Feature Information for Configuring SSG for MAC-Address-Based Authentication
Related Documents
Related Topic
Document Title
Configuring DHCP
“DHCP” section in the Cisco IOS IP Addressing and Services
Configuration Guide, Release 12.4
DHCP Lease Query Support
DHCP Enhancement for Edge-Session Management, feature module
for Cisco IOS Release 12.3(14)T.
RADIUS configuration tasks
“Configuring RADIUS” chapter in the Cisco IOS Security
Configuration Guide, Release 12.4
SSG commands
Cisco IOS Service Selection Gateway Command Reference,
Release 12.4
Technical Assistance
Description
Link
Technical Assistance Center (TAC) home page,
containing 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.
http://www.cisco.com/public/support/tac/home.shtml
Feature Information for Configuring SSG for
MAC-Address-Based Authentication
Table 1 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.3(14)T 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.
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.
Note
Table 1 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.
9
Configuring SSG for MAC-Address-Based Authentication
Feature Information for Configuring SSG for MAC-Address-Based Authentication
Table 1
Feature Information for SSG On-Demand IP Address Renewal
Feature Name
Releases
Feature Configuration Information
MAC-Addressed-Based Authentication for SSG
12.3(14)T
12.4
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.
The following sections provide information about this
feature:
•
Overview of MAC-Address-Based Authentication for
SSG, page 2
•
Subscriber Login with MAC-Address-Based
Authentication for SSG, page 2
•
Benefits of MAC-Address-Based Authentication for
SSG, page 6
•
Configuring a DHCP Lease Query Request for
MAC-Address-Based Authentication, page 6
•
Configuring an IP DHCP Lease Query Request, page 7
•
Configuring SSG for MAC-Address-Based
Authentication: Example, page 8
•
Configuring an IP DHCP Lease Query Request:
Example, page 8
The following commands were introduced by this feature:
query ip dhcp, ssg query mac dhcp, username mac.
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
10
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
This module was first published on May 2, 2005, and last updated on May 2, 2005.
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 SSG Subscriber Services” section on page 43.
Contents
•
Prerequisites for Configuring SSG for Subscriber Services, page 1
•
Information About SSG Support for Subscriber Services, page 2
•
How to Configure Services for Subscribers, page 10
•
Configuration Examples for SSG Support for Subscriber Services, page 31
•
Additional References, page 43
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.
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Configuring SSG for Subscriber Services
Information About SSG Support for Subscriber Services
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 2
•
Authenticated Services, page 2
•
How SSG Routes to Services, page 4
•
Open Garden (Unauthenticated) Services, page 5
•
SSG Uplink Interface Redundancy and Load Balancing, page 6
•
DNS Packet Handling, page 9
•
SSG Transparent Pass-Through, page 9
•
Service Profile Caching, page 10
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:
2
•
Pass-Through Services, page 3
•
Proxy Services, page 3
•
L2TP Dial-In Services, page 3
•
L2TP Dial-Out Services, page 4
•
DNS Packet Handling, page 4
Configuring SSG for Subscriber Services
Information About SSG Support for Subscriber Services
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.
3
Configuring SSG for Subscriber Services
Information About SSG Support for Subscriber Services
For more information about SSG support for L2TP tunnel services, see the “What to Do Next” section
on page 12.
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 17.
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.
4
Configuring SSG for Subscriber Services
Information About SSG Support for Subscriber Services
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 5
•
Access Control Lists in Open Garden Services, page 6
•
Hierarchical Policing in Open Garden Services, page 6
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 1 shows a network topology that includes open
gardens.
Figure 1
Open Garden Network Topology
Open garden 1
Open garden 2
Next-hop gateway
62669
SSG
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.
5
Configuring SSG for Subscriber Services
Information About SSG Support for Subscriber Services
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 6
•
SSG Uplink Interface Redundancy Topologies, page 7
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.
6
Configuring SSG for Subscriber Services
Information About SSG Support for Subscriber Services
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 11. 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 7
•
Multiple Uplink Interfaces with a Single Next Hop, page 8
•
Multiple Uplink Interfaces with No Next Hop, page 8
•
Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops, page 8
Multiple Next Hops per Service
Figure 2 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.
7
Configuring SSG for Subscriber Services
Information About SSG Support for Subscriber Services
Figure 2
Multiple Next Hops per Service: Sample Topology
Next hop 1
Uplink 1
Service
103656
SSG
Uplink 2
Next hop 2
Multiple Uplink Interfaces with a Single Next Hop
Figure 3 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 in the IP routing table.
Figure 3
Multiple Uplink Interfaces with a Single Next Hop: Sample Topology
SSG
Next hop
Service
Uplink 2
103657
Uplink 1
Multiple Uplink Interfaces with No Next Hop
Figure 4 shows an example of SSG interface redundancy configured to support multiple uplink
interfaces that are directly connected to the service. These uplink interfaces could also be tunnel
interfaces.
Figure 4
Multiple Uplink Interfaces with No Next Hop: Sample Topology
SSG
Service
Uplink 2
103658
Uplink 1
Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops
Figure 5 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.
8
Configuring SSG for Subscriber Services
Information About SSG Support for Subscriber Services
Figure 5
Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops:
Sample Topology
SSG
Service
Uplink 2
103659
Uplink 1
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
9
Configuring SSG for Subscriber Services
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.
How to Configure Services for Subscribers
This section contains the following tasks:
•
Configuring a Local Service Profile Using the Cisco IOS CLI, page 10
•
Configuring SSG Support for Services, page 11
•
Configuring SSG to Support L2TP Dial-In Tunnel Services, page 13
•
Configuring SSG to Support L2TP Dial-Out Services, page 17
•
Configuring SSG Open Garden Services, page 26
•
Configuring SSG Transparent Pass-Through, page 27
•
Monitoring and Maintaining SSG Support for Services, page 28
•
Troubleshooting SSG Support for Services, page 30
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.
10
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
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
Command or Action
Purpose
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]
[cisco-vsa-type] attribute-value
Configures an attribute in a local RADIUS service profile.
•
See the “RADIUS Profiles and Attributes for SSG”
module for information about RADIUS profiles and
VSAs for SSG.
•
Only attributes that can appear in RADIUS
Access-Accept packets can be configured using the
attribute command.
Example:
Router(config-prof)# attribute 26 9 251
"Owww.opengarden.com"
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
11
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
DETAILED STEPS
Step 1
Command or Action
Purpose
ssg bind service service-name {ip-address |
interface-type interface-number}
[distance-metric]
Specifies the interface for a service.
•
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
binding is defined in the next-hop table, then it is not
necessary to bind the service by using the ssg bind
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.
Example:
Router(config)# ssg bind service sample-service
atm 1/0.1
Step 2
ssg service-search-order {local | remote |
local remote | remote local}
(Optional) Specifies the order in which SSG searches for a
service profile.
•
The local keyword specifies that service profiles are
configured using local profile.
•
The default value for the service search order is
remote; that is, the SSG searches for service profiles on
the RADIUS server.
Example:
Router(config)# ssg service-search-order local
Step 3
ssg next-hop download [profile-name]
[profile-password]
(Optional) Downloads the next-hop table from a RADIUS
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
Step 5
(Optional) Returns to global configuration mode.
exit
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 13.
12
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
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
Command or Action
Purpose
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
13
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
DETAILED STEPS
Step 1
Command or Action
Purpose
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 1 lists the Cisco AVpair attributes used in the service profile to configure VPDN.
Table 1
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 2 lists the Service-Info attributes used in the service profile to define the L2TP service parameters.
Table 2
14
Service-Info Attributes
Attribute
Description
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.
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
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
Command or Action
Purpose
username name password secret
(Optional) Specifies the password to be used
for PAP and CHAP.
Example:
•
Router(config)# username myusername password mypassword
Step 2
vpdn-group number
Selects the VPDN group.
•
Each L2TP tunnel requires a unique
VPDN group.
•
Enters VPDN group configuration mode.
Example:
Router(config)# vpdn-group 3
Step 3
accept-dialin
Example:
Subscribers can also be defined and
authenticated on the AAA server serving
the LNS.
Creates an accept dial-in VPDN group and
enters VPDN Accept-dialin group
configuration mode.
Router(config-vpdn)# accept-dialin
Step 4
protocol l2tp
Configures the VPDN to use L2TP.
Example:
Router(config-vpdn-acc-in)# protocol l2tp
15
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
Step 5
Command or Action
Purpose
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
Example:
Specifies the tunnel ID that will be required
when a VPDN tunnel is accepted.
•
Router(config-vpdn)# terminate-from hostname myhostname
Step 8
l2tp tunnel password password
This must match the VPDN tunnel ID
configured in the RADIUS service
profile.
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
Example:
Configures the interface as unnumbered and
provides a local address.
•
Enters interface configuration mode.
Router(config-if)# ip unnumbered FastEthernet 1/0
Step 12
peer default ip address pool pool-name
Example:
Specifies the pool from which to retrieve the
IP address to assign to a remote peer dialing in
to the interface.
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
Example:
Router(config-if)# ip local pool mypool 172.16.23.0
172.16.23.255
16
Creates a local IP address pool named
mypool, which contains all local IP addresses
from 172.16.23.0 to 172.16.23.255.
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
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
Command or Action
Purpose
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 |
summary | transport] [id | local-name |
remote-name]
Displays VPDN tunnel information, including tunnel
protocol, ID, packets sent and received, retransmission
times, and transport status.
Example:
Router# show vpdn tunnel summary
Step 3
show vpdn session [all [interface | tunnel |
username]| packets | sequence | state | timers
| window]
Displays VPDN session information, including interface,
tunnel, username, packets, status, and window statistics.
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 18
•
Restrictions for SSG L2TP Dial-Out, page 18
Before you configure SSG support for L2TP dial-out service, you should understand the following
concepts:
•
Overview of SSG L2TP Dial-Out, page 18
17
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
•
SSG L2TP Dial-Out Service Logon Through SESM, page 19
•
SSG L2TP Dial-Out Service Account Logon with Structured Username and Without SSG
Auto-Domain, page 20
•
SSG L2TP Dial-Out Service Logon with Structured Username and with SSG Auto-Domain, page 20
Perform the following tasks to configure SSG support for L2TP dial-out services:
•
Configuring a Global Dial-Out Service Profile, page 21
•
Configuring the User Service Profile for L2TP Dial-Out Services, page 22
•
Configuring a DNIS Filter, page 22
•
Monitoring SSG L2TP Dial-Out, page 23
•
Troubleshooting SSG L2TP Dial-Out User Logon Failures, page 24
•
Troubleshooting SSG L2TP Dial-Out Service Login Failures, page 25
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 13.
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.
18
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
Figure 6
SSG L2TP Dial-Out Network
Subscribers
Services
144.10.50.10
10.10.10.1
SESM
AAA
IP Access
PSTN
L2TP
144.10.50.11
10.10.10.1
75494
LAC
SSG
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.
19
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
Figure 7
SSG L2TP Dial-Out Service Logon Through SESM
Service logon page from SESM
user abc@091805318090
password
*******
SGSN
PPP
LAC
L2TP
091805318090
Dial-up
network
Soho
Dial-up
network
Soho
IP backbone
GN backbone
GGSN
SSG
[LNS]
L2TP
LAC
PPP
03962951
SGSN
password
def@03962951
*******
75493
user
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.
20
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
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
Command or Action
Purpose
ssg dial-out
Enters SSG dial-out configuration mode.
Example:
Router(config)# ssg dial-out
Step 2
dnis-prefix all service service-name
Note
Configures the dial-out global service name.
•
The global service is configured for users who are
doing an account logon with a structured username.
•
service-name—Name of the dial-out global service.
Example:
Router(config-dial-out)# dnis-prefix all
service service1
There is no command to enable or disable the SSG
L2TP Dial-Out feature. An L2TP dial-out tunnel is
established if the service profile contains the
“vpdn:dout-type=2” attribute.
21
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
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 3
MSISDN/DNIS VSA
Attribute ID
Vendor ID
Subattribute ID
and Type
Attribute Name
26
9
251
Subattribute Data
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
22
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
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
DETAILED STEPS
Step 1
Command or Action
Purpose
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:
Router(config-dial-out)# exclude
dnis-prefix 18085288110
dnis-prefix—The DNIS prefix to add to the DNIS exclusion
list.
Step 3
(Optional) Repeat Step 2 to add DNIS prefixes to the DNIS exclusion list.
Step 4
download exclude-profile profile-name
password
(Optional) Downloads the DNIS exclusion list locally or from
AAA.
Example:
Router(config-dial-out)# download
exclude-profile dnis_exclude_profile
safe123
•
profile-name—Name of the DNIS exclusion list.
•
password—Password of the DNIS exclusion list.
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]
3.
show ssg connection ip-address service-name [interface]
DETAILED STEPS
Step 1
Command or Action
Purpose
show ssg dial-out exclude-list
Displays information about the DNIS exclusion list.
Example:
Router# show ssg dial-out exclude-list
23
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
Step 2
Command or Action
Purpose
show ssg service [service-name]
Displays detailed information about a service.
•
If no service name is entered, this command displays a
list of all services.
•
service-name—(Optional) Name of an active SSG
service.
Example:
Router# show ssg service service1
Step 3
show ssg connection ip-address service-name
[interface]
Example:
Router# show ssg connection 10.1.1.19 InstMsg
Displays the connections of a given host and a service name.
•
ip-address—IP address of an active SSG connection.
This is always a subscribed host.
•
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
1.
debug ssg ctrl-events
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.
Router# debug ssg ctrl-events
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.
24
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
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.
Router# debug ssg ctrl-events
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.
25
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
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
Command or Action
Purpose
local-profile profile-name
Creates a local service profile and enters
profile configuration mode.
Example:
Router(config)# local-profile myprofile
Step 2
attribute 26 9 251 “Rip-address;subnet-mask”
Example:
Note
(Service Route attribute) Specifies the
network available to the service.
•
You can add multiple networks to an
open garden service.
•
Repeat step as necessary.
Router(config-prof)# attribute 26 9 251
“R10.10.1.1;255.255.0.0”
26
It is not necessary to create a
local service profile if the service
profile is created on the RADIUS
server.
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
Step 3
Command or Action
Purpose
attribute 26 9 251 “Dip-address”
(DNS Server Address attribute) Specifies
the DNS server for the service.
Example:
•
Router(config-prof)# attribute 26 9 251
“D10.10.2.2”
Step 4
attribute 26 9 251 “Odomain-name”
Example:
Router(config-prof)# attribute 26 9 251 “SSG1”
Step 5
exit
Enter this command twice to specify
two DNS servers for DNS fault
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.
(Domain Name attribute) Specifies the
domain name that gets DNS resolution
from the DNS server specified in Step 3.
•
Repeat step as necessary. You can
add multiple domain names to an
open garden service.
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 |
interface-type interface-number}
Specifies the bindings for the service.
Note
Example:
This step is required only if the
open garden is routed through a
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]
27
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
DETAILED STEPS
Step 1
Command or Action
Purpose
ssg pass-through [filter {ip-access-list |
ip-extended-access-list | access-list-name |
download [profile-name | profile-name
profile-password]} [downlink | uplink]}]
Enables transparent pass-through, which allows
unauthenticated traffic to bypass SSG processing in either
direction without modification.
•
Use the filter options to specify access control for
packets.
•
Use the download options to download a service profile
and use its filters as default filters.
Example:
Router(config)# ssg pass-through filter
download filter01 cisco
Step 2
Returns to privileged EXEC mode.
end
Example:
Router(config)# end
Step 3
show ssg pass-through-filter [begin expression
exclude expression | include expression]
|
(Optional) Displays the downloaded filter for transparent
pass-through.
•
Example:
Use this command to verify transparent pass-through
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.
Router# show ssg pass-through-filter
Service name:
Password:
Direction:
filter01
cisco
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
28
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
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
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
Command or Action
Purpose
show ssg service [service-name [begin
expression | exclude expression | include
expression]]
Displays information for an SSG service.
•
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]
Example:
Lists the SSG-enabled interfaces as uplink, downlink, and
featurelink.
•
Router# Show ssg interface brief
Step 5
show ip nat translations
Lists hosts on downlink interfaces and services bound
to the uplink interfaces.
Lists the NAT entries on SSG.
Example:
Router# Show ip nat translations
Step 6
clear ssg open-garden
Example:
Removes all instances of the ssg open-garden command
from the configuration and removes the service object of all
the open garden services.
Router# clear ssg open-garden
Step 7
clear ssg service profile-name
Removes the service from SSG.
•
Example:
For authenticated services, this command clears all of
the connections (that is, users) logged into that service.
Router# clear ssg service profile-name
29
Configuring SSG for Subscriber Services
How to Configure Services for Subscribers
Command or Action
Step 8
show ssg pass-through-filter [begin expression
exclude expression | include expression]
Purpose
|
(Optional) Displays the downloaded filter for transparent
pass-through.
Example:
Router# show ssg pass-through-filter
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
1.
debug ssg ctrl-events
2.
debug ssg ctrl-errors
3.
debug ssg ctrl-packets
4.
debug ssg events
5.
debug ssg errors
DETAILED STEPS
Step 1
Command or Action
Purpose
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
Accounting).
Example:
Router# debug ssg ctrl-events
•
Step 2
debug ssg ctrl-errors
Example:
Router# 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,
Subblock, and Accounting).
•
Step 3
debug ssg ctrl-packets
Example:
Router# debug ssg ctrl-packets
An error message is the result of an error detected
during normal execution.
Shows packet messages for the control modules. These
modules include all those that manage the user
authentication and service logon and logoff (RADIUS, PPP,
Subblock, and Accounting).
•
30
An event message is an informational message
generated during normal execution.
A packet message displays the contents of a package.
Configuring SSG for Subscriber Services
Configuration Examples for SSG Support for Subscriber Services
Step 4
Command or Action
Purpose
debug ssg events
Displays event messages for the system modules such as
Timeout and Initialization.
•
Example:
Router# debug ssg events
Step 5
An event message is an informational message that
appears during normal execution.
Displays error messages for the system modules such as
Timeout and Initialization.
debug ssg errors
•
Example:
Router# debug ssg errors
An error message is the result of an error detected
during normal execution.
Configuration Examples for SSG Support for Subscriber
Services
This section contains the following examples:
•
Service Profile Configuration: Examples, page 31
•
SSG Support for L2TP Tunnel Services: Examples, page 32
•
SSG Support for L2TP Dial-Out Services: Examples, page 33
•
SSG Interface Redundancy: Examples, page 41
•
SSG Open Garden Services: Example, page 42
•
SSG Transparent Pass-Through: Example, page 42
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
Idle-Timeout
Service-Info
Service-Info
Service-Info
Service-Info
Service-Info
Service-Info
Service-Info
Service-Info
Service-Info
=
=
=
=
=
=
=
=
=
=
Password = "cisco", Service-Type = outbound,
1800,
"R192.168.1.128;255.255.255.192",
"R192.168.2.0;255.255.255.192",
"R192.168.3.0;255.255.255.0",
"Gservice1",
"D192.168.2.81",
"MC",
"TP",
"ICompany Intranet Access",
"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"
31
Configuring SSG for Subscriber Services
Configuration Examples for SSG Support for Subscriber Services
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
interface Virtual-Template1
ip unnumbered FastEthernet0/0
no ip directed-broadcast
peer default ip address pool pool2
ppp authentication pap chap
32
Configuring SSG for Subscriber Services
Configuration Examples for SSG Support for Subscriber Services
SSG Support for L2TP Dial-Out Services: Examples
This section contains the following examples:
•
Configuring SSG L2TP Dial-Out for SSG Without SSG Auto-Domain Enabled: Example, page 33
•
Configuring SSG L2TP Dial-Out for SSG with SSG Auto-Domain Enabled: Example, page 35
•
Configuring SSG L2TP Dial-Out User-Specific Configurations on the SOHO: Example, page 36
•
Configuring a Large-Scale SSG L2TP Dial-Out Solution: Example, page 37
•
Configuring a Global Dial-Out Service Profile: Example, page 39
•
Configuring the Service Profiles for SSG L2TP Dial-Out: Example, page 40
•
Configuring the Service Profile to Send MSISDN Data: Example, page 40
•
Configuring a DNIS Filter: Example, page 40
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 8
Sample SSG L2TP Dial-Out Network
ATM3/0
Subscriber
ATM1/0
SSG
S4/0
LAC
SOHO
75760
AAA/SESM
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 {
radius=6510-SSG-v1.1 {
check_items= {
2=cisco
}
reply_attributes= {
9,250-”Nsoho0”
}
}
}
Use the following profile configuration when the SSG user accesses the SOHO with an account logon
with service configured as an autologon service:
user=abc {
radius-6510-SSG-v1.1 {
33
Configuring SSG for Subscriber Services
Configuration Examples for SSG Support for Subscriber Services
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 {
radius=6510-SSG-v1.1 {
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
aaa authentication ppp default group radius
!
ip cef
! enable vpdn for l2tp dialout
vpdn enable
!
ssg enable
ssg default-network 10.1.1.1 255.255.255.255
ssg service-password cisco
ssg radius-helper auth-port 1645 acct-port 1646
ssg radius-helper key 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
!
interface 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
!
34
Configuring SSG for Subscriber Services
Configuration Examples for SSG Support for Subscriber Services
radius-server host 10.2.36.253 auth-port 1645 acct-port 1646 timeout 5
radius-server retransmit 3
radius-server key ssg
LAC Configuration: Example
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
ppp authentication pap
!
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
ip unnumbered Loopback2
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
dialer-list 1 protocol ip permit
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.
35
Configuring SSG for Subscriber Services
Configuration Examples for SSG Support for Subscriber Services
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
Use the following profile configuration when the SSG user accesses the SOHO with an account logon
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 Configuration: Example
.
.
.
!
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 33 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 33.
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
pri-group timeslots 1-24
!
interface serial1/1:23
no ip address
encapsulation ppp
36
Configuring SSG for Subscriber Services
Configuration Examples for SSG Support for Subscriber Services
dialer pool-member 1
isdn switch-type primary-5ess
no peer default ip address
no cdp enable
ppp authentication chap
!
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
ppp authentication chap
!
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 9
Sample Large-Scale SSG L2TP Dial-Out Network
AAA/SESM
SSG1
LAC10
SOHO10
Subscriber
LAC11
SOHO11
75761
SOHO20
37
Configuring SSG for Subscriber Services
Configuration Examples for SSG Support for Subscriber Services
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 33.
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{
radius=6510-SSG-v1.1 {
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{
radius=6510-SSG-v1.1 {
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"
}
}
}
SSG Configuration: Example
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 33.
LAC Configuration: Example
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.
38
Configuring SSG for Subscriber Services
Configuration Examples for SSG Support for Subscriber Services
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
!
isdn switch-type primary-5ess
!
controller T1 4/0
framing esf
linecode b8zs
pri-group timeslots 1-24
!
interface ATM2/0.1 point-to-point
ip address 100.0.0.2 255.0.0.0
pvc 0/100
!
interface Serial4/0:23
no ip address
encapsulation ppp
dialer rotary-group 0
dialer-group 1
isdn switch-type primary-5ess
!
interface Dialer0
no ip address
encapsulation ppp
dialer in-band
dialer aaa
ppp authentication pap
!
interface Serial4/1:23
no ip address
encapsulation ppp
dialer rotary-group 1
dialer-group 1
isdn switch-type primary-5ess
!
interface Dialer1
no ip address
encapsulation ppp
dialer in-band
dialer aaa
ppp authentication pap
!
dialer-list 1 protocol ip permit
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 33.
Configuring a Global Dial-Out Service Profile: Example
The following example shows how to configure a global dial-out service profile called “dialout_1”:
39
Configuring SSG for Subscriber Services
Configuration Examples for SSG Support for Subscriber Services
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
9,251
9,1 =
9,1 =
9,1 =
9,1 =
9,1 =
= “TT”
= “R172.16.0.0;255.255.0.0;I”
“vpdn:ip-addresses=10.0.0.1”
“vpdn:l2tp-tunnel-password=cisco”
“vpdn:tunnel-type = l2tp”
“vpdn:tunnel-id = ssg1”
“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
radius=6510-SSG-v1.1 {
check_items= {
2=cisco
}
reply_attributes= {
9,253="XD+444"
9,253="XD22222T"
}
40
Configuring SSG for Subscriber Services
Configuration Examples for SSG Support for Subscriber Services
}
}
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
!
interface ATM 1/0.1 point-to-point
ip address 10.1.0.1 255.255.0.0
ssg direction uplink member groupA
!
interface ATM 1/0.2 point-to-point
ip address 10.2.0.1 255.255.0.0
ssg direction uplink member groupA
!
Service Bound to Next Hop with Multiple Uplink Interfaces: Example
In the following example, a service called “sample-serviceA” is bound to next-hop gateway 10.1.1.1.
Next-hop gateway 10.1.1.1 is reachable through two uplink interfaces: Ethernet interface 1/0 and
Ethernet interface 2/0. The group name “service-groupA” indicates that both interfaces share the same
service (“sample-serviceA”).
For any services bound to either of the two interfaces, downstream traffic from the service is accepted
on either interface.
!
ssg bind service sample-serviceA 10.1.1.1
!
interface ethernet 1/0
ip address 10.0.1.1 255.255.255.0
ssg direction uplink member service-groupA
!
interface ethernet 2/0
ip address 10.0.2.1 255.255.255.0
ssg direction uplink member service-groupA
!
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
41
Configuring SSG for Subscriber Services
Configuration Examples for SSG Support for Subscriber Services
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
!
interface ethernet 1/0
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
attribute 26 9 251
attribute 26 9 251
local-profile og2
attribute 26 9 251
attribute 26 9 251
attribute 26 9 251
attribute 26 9 251
!
ssg bind service og2
!
ssg open-garden og1
ssg open-garden ot2
!
"Oopengarden1.com"
"D10.13.1.5"
"R10.1.1.0;255.255.255.0"
"Oopengarden2.com"
"D10.14.1.5"
"R10.2.1.0;255.255.255.0"
"R10.3.1.0;255.255.255.0"
10.5.5.1
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
42
Configuring SSG for Subscriber Services
Additional References
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
Additional References
The following sections provide references related to the Configuring SSG for Subscruber Services
features.
Related Documents
Related Topic
Document Title
SSG commands
Cisco IOS Service Selection Gateway Command Reference,
Release 12.4
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
Configuration Guide, Release 12.4
Technical Assistance
Description
Link
Technical Assistance Center (TAC) home page,
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.
http://www.cisco.com/public/support/tac/home.shtml
Feature Information for SSG Subscriber Services
Table 4 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.
For information on a feature in this technology that is not documented here, see the “Service Selection
Gateway Features Roadmap.”
43
Configuring SSG for Subscriber Services
Feature Information for SSG Subscriber Services
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.
Note
Table 4
Table 4 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.
Feature Information for SSG Subscriber Services
Feature Name
Releases
Feature Configuration Information
SSG L2TP Dial-Out
12.2(15)B
12.2T
12.3(4)T
12.4
The L2TP Dial-Out feature provides mobile users with a
way to securely connect to their SOHOs through the PSTN.
The following sections provide information about this
feature:
•
Configuring SSG to Support L2TP Dial-Out Services,
page 17
The following commands were introduced by this feature:
dnis-prefix all service, ssg dial-out.
SSG Open Garden
12.1(5)DC
12.2(4)B
12.2(8)T
12.2(11)T
12.2(13)T
12.4
The SSG Open Garden feature enables you to use Cisco
SSG to implement open gardens, which are collections of
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.
The following sections provide information about this
feature:
•
Open Garden (Unauthenticated) Services, page 5
•
Configuring SSG Open Garden Services, page 26
The following commands were introduced or modified by
this feature: clear ssg open-garden, local-profile, show ssg
open-garden, ssg open-garden.
44
Configuring SSG for Subscriber Services
Feature Information for SSG Subscriber Services
Table 4
Feature Information for SSG Subscriber Services (continued)
Feature Name
Releases
Feature Configuration Information
SSG Service Logon Enhancements
12.2T
12.3(7)T
The SSG Service Logon Enhancements feature enables SSG
to deliver services to a subscriber after receiving valid
authentication information.
The following section provides information about this
feature:
•
SSG Service Profile Caching
12.2T
12.3(4)T
Authenticated Services, page 2
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.
The following section provides information about this
feature:
•
Service Profile Caching, page 10
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
45
Configuring SSG for Subscriber Services
Feature Information for SSG Subscriber Services
46
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
Finding Feature Information in This Module
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 51.
Finding Support Information for Platforms and Cisco IOS Software Images
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.
Contents
•
Prerequisites for Configuring SSG Subscriber Experience Features, page 2
•
Information About SSG Subscriber Experience Features, page 2
•
How to Configure SSG Subscriber Experience Features, page 19
•
Configuration Examples for Configuring SSG Subscriber Experience Features, page 44
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Configuring SSG Subscriber Experience Features
Prerequisites for Configuring SSG Subscriber Experience Features
•
Additional References Related to SSG Subscriber Experience Features, page 49
•
Feature Information for Configuring SSG Subscriber Experience Features, page 51
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 19.
Before you configure SSG subscriber experience features, review and understand the SSG concepts
provided in the following sections:
2
•
SSG Hierarchical Policing Overview, page 3
•
SSG TCP Redirect Features Overview, page 7
•
Per-Session Firewall Overview, page 14
•
Default DNS Redirection Overview, page 16
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
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 3
•
SSG Hierarchical Policing Token Bucket Scheme, page 4
For detailed information about configuring SSG hierarchical policing, see Configuring SSG Hierarchical
Policing, page 19.
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.
3
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
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 1, 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 1
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
4
The committed rate is specified in bits per second, while the
normal burst and excess-burst sizes are specified in bytes.
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
Table 1
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.
5
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
Table 2 provides a definition of actual and compound debt:
Table 2
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.
6
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
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 7
•
SSG TCP Redirect for Unauthenticated Users, page 7
•
SSG TCP Redirect for Unauthorized Services, page 8
•
SSG TCP Redirect Initial Captivation, page 9
•
SSG TCP Redirect Access Control Lists Overview, page 10
•
SSG Permanent TCP Redirection Overview, page 11
For detailed information about configuring TCP Redirect features, see Configuring SSG TCP
Redirection Features, page 23.
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
7
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
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 1 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 1
Restricting Access to Networks Within Authorized Services
IPTVService 10.1.1.1/32
87908
ServiceA
10.0.0.0/8
The following describes the behavior of redirection for unauthorized services:
8
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
•
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.
9
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
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 10
•
Prevention of Redirection of Non-HTTP Applications, page 10
•
Location-Based Redirections, page 11
•
Redirection to a Service Network for Captivation, page 11
•
Redirection for a Range of TCP Ports, page 11
For information about configuring SSG TCP redirect ACLs, see Associating an Access Control List with
a Redirection Group, page 28.
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.
10
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
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 2 shows an example of a typical wireless LAN (WLAN) topology that uses permanent TCP
redirection.
11
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
Figure 2
Sample WLAN Topology for SSG Permanent TCP Redirection
Cisco SESM
AAA server
IP
network
Access
router
Cisco SSG
95811
Wireless
access
point
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:
12
•
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.
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
•
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 3 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 3
Vendor-Specific RADIUS Attributes for the SSG Permanent TCP Redirection Feature
Attribute ID
Vendor ID
Subattribute
ID
Subattribute
Type
26
9
251
Service-Info
Subattribute Data
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
13
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
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 15, before configuring Per-Session firewalls.
This section describes the following SSG per-session firewall concepts:
•
Access List Attributes for User and Service Profiles, page 14
•
Downstream Access Control List Attribute—outacl, page 14
•
Upstream Access Control List Attribute—inacl, page 15
•
Restrictions for Per-Session Firewall, page 15
For detailed information about configuring per-session firewalls for SSG, see Configuring a Per-Session
Firewall, page 42.
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
14
number
Access list identifier.
standard-access-control-list
Standard access control list.
extended-access-control-list
Extended access control list.
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
Example
Cisco-AVpair = "ip:outacl#101=deny tcp 10.168.1.0 0.0.0.255 any eq 21"
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.
Note
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 |
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.
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.
15
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
•
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 16
•
SSG Domain Name Vendor-Specific Attribute, page 17
•
Restrictions for Dynamic DNS Assignment, page 17
For detailed information about configuring default DNS redirection, see Configuring Default DNS
Redirection, page 42.
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.
16
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
SSG Domain Name Vendor-Specific Attribute
Table 4 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 4
SSG Vendor-Specific Attribute for Domain Name
Attribute ID
Subattribute
Vendor ID ID and Type
Subattribute
Name
Subattribute Data
26
9
Domain Name
O{name1[;name2]...[;nameX] | *[;unauthenticated]}
251
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 18.
17
Configuring SSG Subscriber Experience Features
Information About SSG Subscriber Experience Features
Cisco-AVpair Attributes
The Cisco-AVpair attributes are used in user and service profiles to configure ACLs and L2TP.
Table 5 lists the Cisco-AVpair attributes.
Table 5
Cisco-AVPair Attributes
Attribute
Description
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
Password
Specifies the secret (the password) used for L2TP tunnel authentication.
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.
18
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 Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
This section contains the following tasks:
•
Configuring SSG Hierarchical Policing, page 19
•
Configuring SSG TCP Redirection Features, page 23
•
Configuring a Per-Session Firewall, page 42
•
Configuring Default DNS Redirection, page 42
For conceptual information about SSG subscriber experience features, see Information About SSG
Subscriber Experience Features, page 2.
Configuring SSG Hierarchical Policing
Perform the following tasks to configure SSG hierarchical policing:
•
Configuring a RADIUS User Profile for Per-User Policing, page 19
•
Configuring SSG Hierarchical Policing in a RADIUS Service Profile, page 19
•
Enabling SSG Hierarchical Policing on the Router, page 21
•
Troubleshooting SSG Hierarchical Policing, page 22
For conceptual information about SSG hierarchical policing, see SSG Hierarchical Policing Overview,
page 3.
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.
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.
19
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
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
2.
configure terminal
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”
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables priviledged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Example:
Router# configure terminal
20
Enters global configuration mode.
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
Step 3
Command or Action
Purpose
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
“QU;upstream-token-rate;upstream-normal-burst;
[upstream-excess-burst];D;downstream-token-rate;
downstream-normal-burst;downstream-excess-burst”
Example:
Router(config-prof)# attribute 26 9 251“QU;80000;40000;
50000;D;downstream-token-rate;40000;50000”
Configures the policing attributes in a local
RADIUS service profile.
The Q parameter (as shown in the command)
represents QoS. The variables are used to
configure upstream (U) and downstream (D)
policing. The upstream traffic is the traffic
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
2.
configure terminal
3.
ssg qos police user
4.
ssg qos police session
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables priviledged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
21
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
Step 3
Command or Action
Purpose
ssg qos police user
Enables SSG per-user policing on the router.
Example:
Router(config)# ssg qos police user
Step 4
Enables SSG per-session policing.
ssg qos police session
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
DETAILED STEPS
Step 1
Command or Action
Purpose
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:
Step 2
Router# show ssg host
Ust the show ssg host command to verify per-user policing.
show ssg connection
Displays information about a particular SSG connection, including
the policing parameters.
Example:
Router# show ssg connection
Step 3
debug ssg data
Example:
Router# debug ssg data
22
Displays SSG QoS information.
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
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 7.
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 23
•
Defining a Captive Portal Group, page 25
•
Configuring Initial and Periodic Captivation, page 26
•
Associating an Access Control List with a Redirection Group, page 28
•
Verifying SSG TCP Redirect Access Control Lists, page 30
•
Configuring TCP Redirection of Unauthenticated Subscribers, page 31
•
Configuring TCP Ports for Redirection, page 32
•
Configuring Unauthorized Service Redirection, page 33
•
Configuring SMTP Redirection, page 35
•
Configuring the RADIUS Attributes for SSG TCP Redirection, page 36
•
Configuring Permanent TCP Redirection for HTTP Proxy Support, page 36
•
Verifying SSG TCP Redirect for Services, page 38
•
Troubleshooting SSG TCP Redirection, page 40
For conceptual information about SSG TCP Redirection features, see SSG TCP Redirect Features
Overview, page 7.
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.
23
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
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.
1.
enable
2.
configure terminal
3.
ip cef
4.
ssg enable
5.
ssg tcp-redirect
SUMMARY STEPS
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables priviledged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Example:
Router# configure terminal
24
Enters global configuration mode.
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
Step 3
Command or Action
Purpose
ip cef
Enables global IP CEF on the router.
Example:
Router(config)# ip cef
Step 4
Enables SSG functionality.
ssg enable
Example:
Router(config)# ssg enable
Step 5
ssg tcp-redirect
Enables SSG TCP redirect.
Example:
Router(config)# ssg tcp-redirect
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
2.
configure terminal
3.
ssg tcp-redirect
4.
server-group group-name
5.
server ip-address port
6.
(Optional) Repeat steps 3. to 5. for each captive portal group.
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables priviledged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
25
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
Step 3
Command or Action
Purpose
ssg tcp-redirect
Enables SSG TCP redirect.
Example:
Router(config)# ssg tcp-redirect
Step 4
server-group group-name
Example:
Step 5
Defines the group of one or more servers that
make up a named captive portal group and
enters SSG-redirect-group configuration mode.
Router(config-ssg-redirect)# server-group capt_portgroup
group-name—Name of the captive portal group.
server ip-address port
Adds a server to a captive portal group.
•
ip-address—IP address of the server to add
to the captive portal group.
•
port—TCP port of the server to add to the
captive portal group.
Example:
Router(config-ssg-redirect-group)# server 10.2.2.2 24
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
2.
configure terminal
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
Step 1
Command or Action
Purpose
enable
Enables priviledged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2
configure terminal
Example:
Router# configure terminal
26
Enters global configuration mode.
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
Step 3
Command or Action
Purpose
ssg tcp-redirect
Enables SSG TCP redirect.
Example:
Router(config)# ssg tcp-redirect
Step 4
redirect captivate initial default group group-name
duration seconds
Selects the default captive portal group for
initial captivation of users upon initialization.
•
group-name—Name of the captive portal
group.
•
seconds—The duration in seconds of the
initial captivation. The valid range is 1 to
65,536 seconds.
Example:
Router(config-ssg-redirect)# redirect captivate initial
default group group-name duration seconds
Step 5
redirect captivate advertising default group group-name
duration seconds frequency frequency
Selects the default captive portal group for
captivation of advertisements for users.
•
group-name—Name of the captive portal
group.
•
seconds—The duration in seconds of the
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.
Example:
Router(config-ssg-redirect)# redirect captivate
advertising default group group-name duration seconds
frequency frequency
27
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
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
2.
configure terminal
3.
ssg tcp-redirect
4.
server-group group-name
5.
server ip-address port
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
Step 1
Command or Action
Purpose
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
ssg tcp-redirect
Enables SSG TCP redirect functionality and enters
SSG-redirect configuration mode.
Example:
Router(config)# ssg tcp-redirect
Step 4
server-group group-name
Example:
Router(config-ssg-redirect)# server-group SESM1
28
Defines the group of one or more servers that make up a
named captive portal group and enters SSG-redirect-group
configuration mode.
•
group-name—Name of the captive portal group.
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
Step 5
Command or Action
Purpose
server ip-address port
Adds a server to a captive portal group.
•
ip-address—IP address of the server to add to the
captive portal group.
•
port—TCP port of the server to add to the captive portal
group.
Example:
Router(config-ssg-redirect-group)# server
10.10.10.10 8080
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
or
(Optional) Configures a TCP port or named TCP port list
for SSG TCP redirection.
•
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.
•
port-number—Specifies the incoming destination port
number of the TCP port to mark for SSG TCP
redirection.
•
group-name—Defines the name of the captive 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.
redirect port-list port-listname to group-name
Example:
Router(config-ssg-redirect)# redirect port 80
to SESM1
or
Router(config-ssg-redirect)# redirect port-list
portlist1 to SESM1
Step 8
redirect access-list {number | name}[to
group-name]
Configures an access control list for SSG TCP redirection.
•
Example:
If a server group is not specified, the access list is used
for redirection to any server group that does not have an
access list associated with it.
Router(config-ssg-redirect)# redirect
access-list 80 to SESM1
29
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
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
Command or Action
Purpose
show ssg tcp-redirect group
Displays a list of all defined portal groups.
Example:
Verifies that the default access list for
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
listed in the server group configuration in the
output.
Router# show ssg tcp-redirect group SESM1
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
30
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
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
2.
configure terminal
3.
ssg tcp-redirect
4.
redirect unauthenticated-user to group-name
DETAILED STEPS
Step 1
Command or Action
Purpose
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
ssg tcp-redirect
Enables SSG TCP redirect.
Example:
Router(config)# ssg tcp-redirect
Step 4
redirect unauthenticated-user to group-name
Example:
Router(config-ssg-redirect)# redirect
unauthenticated-user to mygroupname
Selects a captive portal group for redirection of
traffic from unauthenticated users.
•
group-name—Name of the captive portal
group.
31
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
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
2.
configure terminal
3.
ssg tcp-redirect
4.
port-list port-listname
5.
port port-number
6.
exit
7.
redirect port port-number to group-name
or
redirect port-list port-listname to group-name
DETAILED STEPS
Step 1
Command or Action
Purpose
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
ssg tcp-redirect
Enables SSG TCP redirect.
Example:
Router(config)# ssg tcp-redirect
Step 4
port-list port-listname
Example:
Defines the port list and enters SSG-redirect-port
configuration mode.
•
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.
•
Example:
Router(config-ssg-redirect-port)# port 65534
32
port-number—Incoming destination port
number. The valid range of port numbers is 1 to
65535
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
Step 6
Command or Action
Purpose
exit
Exits SSG-redirect-port configuration mode.
Example:
Router(config-ssg-redirect-port)# exit
Step 7
redirect port port-number to group-name
or
redirect port-list port-listname to group-name
Example:
Router(config-ssg-redirect)# redirect port 65534 to
myportgroup
Configures a TCP port or named TCP port list for
SSG TCP redirection.
•
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.
•
port-number—Specifies the incoming
destination port number of the TCP port to mark
for SSG TCP redirection.
•
group-name—Defines the name of the captive
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.
or
Router(config-ssg-redirect)# redirect port-list
myportlist to myportgroup
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
2.
configure terminal
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
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
33
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
Step 2
Command or Action
Purpose
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
ssg tcp-redirect
Enables SSG TCP redirect.
Example:
Router(config)# ssg tcp-redirect
Step 4
network-list network-listname
Example:
Defines the network list and enters
SSG-redirect-network configuration mode.
•
Router(config-ssg-redirect)# network-list
mynetworklist
Step 5
network ip-address
Example:
Adds the specified IP address to the named network
list.
•
Router(config-ssg-redirect-network)# network
ip-address 10.2.2.2
Step 6
exit
network-listname—Defines the name of the
network list.
ip-address—The IP address to add to a named
network list.
Exits SSG-redirect-network configuration mode.
Example:
Router(config-ssg-redirect-network)# exit
Step 7
redirect unauthorized-service [destination
network-list network-listname] to group-name
Creates a list of destination IP networks that can be
redirected by the named captive portal group.
•
(Optional) destination network-list—Checks
to determine if incoming packets from
authenticated hosts require redirection to
authorized networks.
•
(Optional) network-listname—Name of the list
of destination IP networks.
•
group-name—Name of the captive portal group.
Example:
Router(config-ssg-redirect)# redirect
unauthorized-service destination network-list
mynetworklist to myportgroup
Note
34
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.
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
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
2.
configure terminal
3.
ssg tcp-redirect
4.
redirect smtp group group-name [all | user]
DETAILED STEPS
Step 1
Command or Action
Purpose
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
ssg tcp-redirect
Enables SSG TCP redirect.
Example:
Router(config)# ssg tcp-redirect
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.
35
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
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 6 lists vendor-specific RADIUS attributes required in the user profile to perform SSG TCP
redirection.
Table 6
Vendor-Specific RADIUS Attributes for the SSG TCP Redirect for Services Feature
Attribute
ID
VendorID
SubAttrID
SubAttr Name
SubAttrDataType
Account-Info
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 25.
•
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
36
1.
enable
2.
configure terminal
3.
ssg tcp-redirect
4.
redirect permanent http authenticated to server-group
5.
redirect permanent http unauthenticated to server-group
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
6.
end
7.
Configure the RADIUS service profile to support permanent TCP redirection, see “RADIUS
Attributes for SSG Permanent TCP Redirection” section on page 13.
DETAILED STEPS
Step 1
Command or Action
Purpose
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
ssg tcp-redirect
Enables SSG TCP redirect and enters SSG-redirect
configuration mode.
Example:
Router(config)# ssg tcp-redirect
Step 4
redirect permanent http authenticated to
server-group
Specifies a server group for permanent TCP redirections for
authenticated users with HTTP proxy server configurations.
•
Example:
server-group—Name of the local HTTP proxy server
group for authenticated users
Router(config-ssg-redirect)# redirect permanent
http authenticated to auth_servergroup
Step 5
redirect permanent http unauthenticated to
server-group
Example:
Specifies a server group for permanent TCP redirections for
unauthenticated users with HTTP proxy server
configurations.
•
Router(config-ssg-redirect)# redirect permanent
http unauthenticated to unauth_servergroup
Step 6
end
server-group—Name of the local HTTP proxy server
group for unauthenticated users
(Optional) Returns to global configuration mode.
Example:
Router(config-ssg-redirect)# end
Step 7
Configure the RADIUS service profile to support
permanent TCP redirection.
The RADIUS service profile is downloaded from the AAA
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 13 for more information about
the RADIUS attributes for permanent TCP redirection.
37
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
Verifying SSG TCP Redirect for Services
Use the following show commands to verify the SSG TCP Redirect for Services configuration.
SUMMARY STEPS
1.
show running-config
2.
show ssg tcp-redirect group [group-name]
3.
show ssg tcp-redirect mappings [ip-address [interface]]
4.
show ssg host ip-address
DETAILED STEPS
Step 1
Command or Action
Purpose
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]
Example:
Router# show ssg tcp-redirect group
Current TCP redirect groups:
RedirectServer
CaptivateServer
SMTPServer
SSD
Unauthenticated user redirect group:RedirectServer
Default service redirect group:SSD
SMTP forwarding group:SMTPServer, for all users
Default initial captivation group:CaptivateServer,
for 10 seconds
Default advertising captivation group:CaptivateServer,
for 30 seconds approximately every 3600 seconds
38
Displays a list all configured captive portal
groups, and indicates which group is used for
redirected packets from unauthorized users.
This show command also displays which captive
portal groups are the default groups for
captivation and unauthorized service
redirection.
•
group-name—(optional) Name of the
captive portal group.
If you do not enter the optional group-name
argument, the show ssg tcp-redirect group
command displays a list of all defined portal
groups. If the group-name argument is included,
the command displays information about the
specified portal group.
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
Step 3
Command or Action
Purpose
show tcp-redirect mappings [ip-address [interface]]
Displays any direct mappings, and TCP redirect
statements in the output.
Example:
•
If you do not enter the optional ip-address
argument, the show tcp-redirect mappings
command displays a list of IP addresses for
all hosts with stored mappings. If the
ip-address argument is included, all
mappings for the host with the specified IP
address are displayed.
Router# show tcp-redirect mappings
Authenticated hosts:
TCP remapping Host:10.16.10.0 to servers (IP:Port)
10.2.36.253:8080
10.64.131.20:25
### Total authenticated hosts being redirected = 1
Unauthenticated hosts:
TCP remapping Host:10.0.0.2 to server:10.2.36.253 on
port:80 80
Router# show tcp-redirect mappings 10.16.0.0
TCP remapping Host:10.16.10.0
TCP remapping to server:10.2.36.253 on port:8080
Connection Mappings (src port <-> dest IP,dest
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
ip-address—(optional) The host IP address.
•
interface—(optional) The interface on
which the host is connected to SSG.
Use the optional interface argument in port
bundle host key mode to specify the
interface on which the host is connected to
the SSG. Use the output displayed by this
command to distinguish hosts with
overlapping IP addresses.
39
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
Step 4
Command or Action
Purpose
show ssg host ip-address
Displays information about a subscriber that is
specified by the entered IP address.
Example:
Router# show ssg host 10.16.0.0
--------- 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 policing disabled
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]
2.
show ssg tcp-redirect group [group-name]
3.
show tcp-redirect mappings [ip-address] [interface]
4.
debug ssg tcp-redirect {packet | error | event}
DETAILED STEPS
Step 1
Command or Action
Purpose
show ssg host [ip-address]
Displays information about a subscriber and current
connections of the subscriber.
Example:
Router# show ssg host 10.168.0.0
40
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
Step 2
Command or Action
Purpose
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
specified, this command displays detailed
information about that captive portal group.
Example:
Router# show ssg tcp-redirect group mygroup
Step 3
show tcp-redirect mappings [ip-address] [interface]
Example:
Router# show tcp-redirect mappings 10.168.0.1
myinterface
Step 4
debug ssg tcp-redirect {packet | error | event}
Example:
Displays the redirect mappings currently stored in
SSG. If the host ip-address is provided, this
command displays detailed redirect mapping
information for the specified host. The TCP redirect
mappings are removed automatically after the TCP
session terminates or is idle for more than 60
seconds.
Use this command to turn on debug information for
the SSG TCP Redirect for Services feature.
•
packet—Displays redirection information and
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.
Router# debug ssg tcp-redirect packet
41
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
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 14.
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)
Cisco-AVpair = "ip:outacl[#number]={standard-access-control-list |
extended-access-control-list}"
•
Upstream Access Control List (inacl)
Cisco-AVpair = "ip:inacl[#number]={standard-access-control-list |
extended-access-control-list}"
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):
Cisco-AVpair = "ip:outacl#101=deny tcp 10.168.1.0 0.0.0.255 any eq 21"
The following is an example of an upstream ACL (inacl):
Cisco-AVpair = "ip:inacl#101=deny tcp 10.168.1.0 0.0.0.255 any eq 21"
Configuring Default DNS Redirection
Note
Certain restrictions apply when configuring default DNS redirection. Before configuring default DNS
redirection, see Default DNS Redirection Overview, page 16.
Perform the following tasks to configure default DNS redirection:
•
Configuring DNS Redirection in a Local Service Profile using the Cisco IOS CLI, page 43
•
Configuring Dynamic DNS Assignment on the AAA Server, page 44
•
Configuring DNS Fault tolerance, page 44
For conceptual information about default DNS redirection,see Default DNS Redirection Overview,
page 16.
42
Configuring SSG Subscriber Experience Features
How to Configure SSG Subscriber Experience Features
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 17 for information about the Domain Name VSA.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
local-profile profile-name
4.
attribute 26 9 251 "O*[;unauthenticated]"
5.
end
6.
show ssg service [service-name [begin expression | exclude expression | include expression]]
DETAILED STEPS
Step 1
Command or Action
Purpose
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
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*"
Step 5
end
(Optional) Returns to privileged EXEC mode.
Example:
Router(config-prof)# end
Step 6
show ssg service [service-name [begin
expression | exclude expression | include
expression]]
(Optional) Displays the information for about a service. The
output for this command indicates if default DNS matching
is enabled and whether it is valid for unauthenticated users
only.
Example:
Router# show ssg service og-dns
43
Configuring SSG Subscriber Experience Features
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 17.
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 17 for information about the Domain Name
VSA.
Configuration Examples for Configuring SSG Subscriber
Experience Features
This section provides the following configuration examples:
44
•
Enabling SSG TCP Redirect for Services: Example, page 45
•
Defining a Captive Portal Group: Example, page 45
•
Excluding Specific Traffic from Redirection: Example, page 45
•
Redirecting Traffic from Unauthenticated Users: Example, page 45
•
Configuring TCP Redirection of Unauthenticated Subscribers: Example, page 46
•
TCP Ports for a Portal Group Configuration: Example, page 46
•
Default Portal Group for Captivation: Example, page 46
•
Destination Networks Configuration: Example, page 47
•
Portal Group for SMTP Redirect Configuration: Example, page 47
•
RADIUS Attributes for SSG TCP Redirect Configuration: Example, page 47
•
SSG Default DNS Redirection Configuration: Example, page 48
•
SSG Default DNS Redirection for Unauthenticated Users Configuration: Example, page 48
Configuring SSG Subscriber Experience Features
Configuration Examples for Configuring SSG Subscriber Experience Features
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
45
Configuring SSG Subscriber Experience Features
Configuration Examples for Configuring SSG Subscriber Experience Features
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
46
Configuring SSG Subscriber Experience Features
Configuration Examples for Configuring SSG Subscriber Experience Features
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-list RedirectNw
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-list RedirectNw
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:
47
Configuring SSG Subscriber Experience Features
Configuration Examples for Configuring SSG Subscriber Experience Features
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
48
Configuring SSG Subscriber Experience Features
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.
49
Configuring SSG Subscriber Experience Features
Additional References Related to SSG Subscriber Experience Features
Related Documents
Related Topic
Document Title
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
feature. Support for existing MIBs has not been
modified by this feature.
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
RFCs
RFCs
Title
No new or modified RFCs are supported by this
feature. Support for existing RFCs has not been
modified by this feature.
—
Technical Assistance
Description
Link
Technical Assistance Center (TAC) home page,
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.
http://www.cisco.com/public/support/tac/home.shtml
50
Configuring SSG Subscriber Experience Features
Feature Information for Configuring SSG Subscriber Experience Features
Feature Information for Configuring SSG Subscriber Experience
Features
Table 7 lists the features in this module and provides links to specific configuration information.
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.
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.
Note
Table 7
Table 7 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.
Feature Information for Configuring SSG Subscriber Experience Features
Feature Name
Releases
Feature Configuration Information
Hierarchical Policing
12.2(4)B
12.2(13)T
The SSG Hierarchical Policing feature ensures that a
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.
The following section provides information about this
feature:
SSG TCP Redirect
12.1(5)DC
12.2(4)B
12.2(8)T
12.3T
12.4
•
“SSG Hierarchical Policing Overview” on page 3
•
“Configuring SSG Hierarchical Policing” on page 19
•
“Configuration Examples for Configuring SSG
Subscriber Experience Features” on page 44
The SSG TCP Redirect feature redirects certain packets,
which would otherwise be dropped, to captive portals that
can handle the packets in a suitable manner.
The following sections provide information about this
feature:
•
“SSG TCP Redirect Features Overview” on page 7
•
“Configuring SSG TCP Redirection Features” on
page 23
•
“Configuration Examples for Configuring SSG
Subscriber Experience Features” on page 44
The following commands are introduced in this feature:
ssg tcp-redirect, redirect unauthenticated-user to.
51
Configuring SSG Subscriber Experience Features
Feature Information for Configuring SSG Subscriber Experience Features
Table 7
Feature Information for Configuring SSG Subscriber Experience Features (continued)
Feature Name
Releases
Feature Configuration Information
Per-Session Firewall
12.0(3)DC
12.2(4)B
12.2(8)T
The SSG Per Session Firewall feature enables you to
configure Cisco IOS software access control lists (ACLs) to
prevent users, services, and pass-through traffic from
accessing specific IP addresses and ports.
The following section provides information about this
feature:
DNS Redirection
12.3(3)B
12.3(7)T
•
“Per-Session Firewall Overview” on page 14
•
“Configuring a Per-Session Firewall” on page 42
•
“Configuration Examples for Configuring SSG
Subscriber Experience Features” on page 44
The SSG DNS Redirection feature enables you to match a
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.
The following section provides information about this
feature:
52
•
“Default DNS Redirection Overview” on page 16
•
“Configuring Default DNS Redirection” on page 42
•
“Configuration Examples for Configuring SSG
Subscriber Experience Features” on page 44
Configuring SSG Subscriber Experience Features
Feature Information for Configuring SSG Subscriber Experience Features
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
53
Configuring SSG Subscriber Experience Features
Feature Information for Configuring SSG Subscriber Experience Features
54
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
This module was first published on May 2, 2005, and last updated on May 2, 2005.
Finding Support Information for Platforms and Cisco IOS Software Images
Your Cisco IOS software release may not support all features. To find information about feature support
and configuration, use the “Feature Information for Configuring SSG to Log Off Subscribers” section
on page 8.
Contents
•
Prerequisites for Configuring SSG to Log Off Subscribers, page 1
•
Information About Configuring SSG to Log Off Subscribers, page 2
•
How to Configure SSG to Log Off Subscribers, page 4
•
Configuration Examples for Configuring SSG to Log Off Subscribers, page 7
•
Additional References, page 7
Prerequisites for Configuring SSG to Log Off Subscribers
Before you can perform the tasks in this module, SSG must be enabled.
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Configuring SSG to Log Off Subscribers
Information About Configuring SSG to Log Off Subscribers
The tasks in this document assume that you know how to configure Address Resolution Protocol (ARP)
and Internet Control Message Protocol (ICMP).
Information About Configuring SSG to Log Off Subscribers
To configure SSG to log off subscribers, you should understand the following concepts:
•
Graceful Logoff, page 2
•
Disconnection Through the Web Services Gateways, page 2
•
SSG Autologoff, page 2
•
SSG Session Timeout and Idle Timeout, page 3
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 2
•
SSG Autologoff Using ICMP Ping, page 3
•
MAC Address Checking for Autologoff, page 3
•
Benefits of SSG Autologoff, page 3
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.
2
Configuring SSG to Log Off Subscribers
Information About Configuring SSG to Log Off Subscribers
If any data traffic is flowing to or from the host during the interval, SSG does not ping the host.
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:
3
Configuring SSG to Log Off Subscribers
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.
How to Configure SSG to Log Off Subscribers
This section contains the following tasks:
•
Configuring SSG Autologoff, page 4
•
Configuring Global SSG Session Timeouts and Idle Timeouts, page 5
•
Troubleshooting SSG Subscriber Logoff, page 6
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.
1.
ssg auto-logoff arp [match-mac-address] [interval seconds]
2.
ssg auto-logoff icmp [timeout milliseconds] [packets number] [interval seconds]
SUMMARY STEPS
4
Configuring SSG to Log Off Subscribers
How to Configure SSG to Log Off Subscribers
DETAILED STEPS
Step 1
Command or Action
Purpose
ssg auto-logoff arp [match-mac-address] [interval
seconds]
Configures SSG to automatically log off hosts and to
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
number] [interval seconds]
Configures SSG to automatically log off hosts that
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
Command or Action
Purpose
ssg timeouts
Enters SSG timeouts configuration mode.
Example:
Router(config)# ssg timeouts
5
Configuring SSG to Log Off Subscribers
How to Configure SSG to Log Off Subscribers
Step 2
Command or Action
Purpose
idle seconds
Sets the global idle timeout.
Example:
Router(ssg-timeouts)# idle 60
Step 3
Sets the global session timeout.
session seconds
Example:
Router(ssg-timeouts)# session 60
Troubleshooting SSG Subscriber Logoff
To troubleshoot SSG subscriber logoff, perform the following steps in any order.
SUMMARY STEPS
1.
debug ssg ctrl-errors
2.
debug ssg ctrl-events
3.
debug ssg ctrl-packets
4.
debug ssg data
DETAILED STEPS
Step 1
Command or Action
Purpose
debug ssg ctrl-errors
Displays all error messages for control modules.
Example:
Router# debug ssg ctrl-errors
Step 2
debug ssg ctrl-events
Displays all event messages for control modules, including
autologoff events.
Example:
Router# debug ssg ctrl-events
Step 3
debug ssg ctrl-packets
Displays packet contents handled by control modules.
Example:
Router# debug ssg ctrl-packets
Step 4
debug ssg data
Example:
Router# debug ssg data
6
Displays all data-path packets.
Configuring SSG to Log Off Subscribers
Configuration Examples for Configuring SSG to Log Off Subscribers
Configuration Examples for Configuring SSG to Log Off
Subscribers
This section provides the following configuration examples:
•
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
Additional References
The following sections provide references related to disconnecting SSG subscribers and services.
7
Configuring SSG to Log Off Subscribers
Feature Information for Configuring SSG to Log Off Subscribers
Related Documents
Related Topic
Document Title
Configuring SESM
Cisco Subscriber Edge Services Manager documentation.
Configuring RADIUS
“Configuring RADIUS” chapter in the Cisco IOS Security
Configuration Guide, Release 12.4
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)
Technical Assistance
Description
Link
Technical Assistance Center (TAC) home page,
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.
http://www.cisco.com/public/support/tac/home.shtml
Feature Information for Configuring SSG to Log Off Subscribers
Table 1 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(15)B 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.
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.
8
Configuring SSG to Log Off Subscribers
Feature Information for Configuring SSG to Log Off Subscribers
Note
Table 1
Table 1 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.
Feature Information for Configuring SSG to Log Off Subscribers
Feature Name
Releases
Feature Configuration Information
SSG Autologoff
12.2(15)B
12.3(4)T
12.4
The SSG Autologoff feature supports methods to log
subscribers out of SSG.
The following sections provide information about this
feature:
•
Graceful Logoff, page 2
•
Disconnection Through the Web Services Gateways,
page 2
•
SSG Autologoff, page 2
•
SSG Session Timeout and Idle Timeout, page 3
•
Configuring SSG Autologoff, page 4
•
Configuring Global SSG Session Timeouts and Idle
Timeouts, page 5
•
Troubleshooting SSG Subscriber Logoff, page 6
•
SSG Autologoff Using ARP Ping: Example, page 7
•
SSG Autologoff Using ICMP Ping: Example, page 7
•
SSG MAC Address Checking for Autologoff: Example,
page 7
The following command was introduced by this feature: ssg
auto-logoff arp.
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
9
Configuring SSG to Log Off Subscribers
Feature Information for Configuring SSG to Log Off Subscribers
10
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
This module was first published on May 2, 2005, and last updated on February 9, 2007.
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 SSG Accounting” section on page 30.
Contents
•
Prerequisites for SSG Accounting, page 1
•
Information About SSG Accounting, page 1
•
How to Configure SSG Accounting, page 18
•
Configuration Examples for SSG Accounting, page 28
•
Additional References, page 29
•
Additional References, page 29
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:
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Configuring SSG Accounting
Information About SSG Accounting
•
RADIUS Accounting Records Used by SSG, page 2
•
Types of SSG Accounting, page 4
•
SSG Prepaid Functionality, page 5
•
Prepaid Tariff Switching, page 13
•
Extended Prepaid Tariff Switching for SSG, page 17
•
Postpaid Tariff Switching for SSG, page 17
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 2
•
Service Logon and Logoff, page 3
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.
User-Name = “user1”
Acct-Status-Type = Stop
Acct-Authentic = RADIUS
Service-Type = Framed
Framed-Protocol = PPP
NAS-IP-Address = 192.168.0.0
2
Configuring SSG Accounting
Information About SSG Accounting
NAS-Port-Type = Virtual
Acct-Session-Time = 77
Acct-Terminate-Cause = User-Request
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.
User-Name = “user1”
Acct-Status-Type = Start
Acct-Authentic = RADIUS
Service-Type = Framed
Framed-Protocol = PPP
NAS-IP-Address = 192.168.2.48
NAS-Port-Type = Virtual
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.
User-Name = “user1”
Acct-Status-Type = Stop
Acct-Authentic = RADIUS
Service-Type = Framed
Framed-Protocol = PPP
NAS-IP-Address = 192.168.2.48
NAS-Port = 0
NAS-Port-Type = Virtual
3
Configuring SSG Accounting
Information About SSG Accounting
Acct-Session-Id = "00000002"
Acct-Terminate-Cause = User-Request
Acct-Session-Time = 84
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 4
•
Per-Host Accounting, page 4
•
Per-Service Accounting, page 5
•
SSG Accounting Update Interval per Service Feature, page 5
•
Broadcast Accounting, page 5
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.
4
Configuring SSG Accounting
Information About SSG Accounting
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 1 describes the elements of the Service Authorization VSA.
5
Configuring SSG Accounting
Information About SSG Accounting
Table 1
Service Authorization VSA Elements
Subattribute
Attribute ID Vendor ID ID and Type
26
9
Attribute Name
251
Service-Info
Subattribute Data
Service Authorization The value “Z” indicates that
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 6
•
Service Reauthorization, page 8
•
Accounting Records and Prepaid Billing, page 8
•
Simultaneous Volume- and Time-Based Prepaid Billing, page 9
•
SSG Prepaid Idle Timeout, page 9
•
SSG Prepaid Reauthorization Threshold, page 11
•
SSG Prepaid Redirection on Quota Exhaustion Feature, page 11
•
Default Quota for Prepaid Server Failure, page 12
•
Benefits of the SSG Prepaid Feature, page 12
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 2.
Table 2
6
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).
Configuring SSG Accounting
Information About SSG Accounting
Table 2
Contents of Service Authorization Request Packet (continued)
Attribute ID Attribute Name
Description
Notes
31
Calling-Station-ID
Mobile Station ISDN
Number (MSISDN)
The username or MAC address may
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 3. Access to the service is provided based on the
presence and contents of the Quota VSA in the Access-Accept packet listed in Table 4.
Table 3
Content of Service Authorization Access-Accept Packet
Attribute ID Attribute Name
Description
Notes
6
Service-Type
Framed-user
—
26
Vendor-Specific
Quota
Subattribute ID: 253. The value “Q”
indicates that this is the Quota VSA.
Table 4
Quota VSA Elements
Subattribute
Attribute ID Vendor ID ID and Type
Attribute Name
Subattribute Data
26
Quota
Q—Control-Info code for prepaid
quota.
9
253
Control-Info
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.
7
Configuring SSG Accounting
Information About SSG Accounting
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 4. The content of the Service Reauthorization Request is described in
Table 5.
Table 5
Contents of Service Reauthorization Request
Attribute ID Attribute Name
Description
Notes
1
User-Name
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).
26
Vendor-Specific
Quota
Subattribute ID 253.
The Quota Used VSA has the
same format as the Quota
VSA.
26
Vendor-Specific
Upstream traffic bytes
Subattribute ID 253; code 0.
26
Vendor-Specific
Downstream traffic bytes
Subattribute ID 253; code 1.
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:
8
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.
Configuring SSG Accounting
Information About SSG Accounting
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 6 describes the attributes contained in a
Service-Authorization response packet.
Table 6
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.
9
Configuring SSG Accounting
Information About SSG Accounting
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 7.
Table 7
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 8.
Table 8
10
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.
Configuring SSG Accounting
Information About SSG Accounting
Table 8
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.
11
Configuring SSG Accounting
Information About SSG Accounting
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 9 describes
the Prepaid Default Quota VSA.
Table 9
Prepaid Default Quota VSA
Attribute ID
Vendor ID
Subattribute ID
and Type
26
9
251 Service-Info
Attribute Name
Subattribute Data
Prepaid Default
Quota
PZQT seconds—sets a default
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.
12
Configuring SSG Accounting
Information About SSG Accounting
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 10 describes the behavior of SSG in the various events that occur when prepaid tariff switching
takes place.
13
Configuring SSG Accounting
Information About SSG Accounting
Table 10
Authorization and Reauthorization Behavior
Event
Action
An authorization response is received
containing the dual-quota token tariff
switch attribute.
Tariff switching is enabled on SSG for a given prepaid
connection.
During data forwarding, the quota runs
out before the tariff switch occurs.
SSG performs a reauthorization in the same way as in a no
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
out after the tariff switch.
SSG will send the quota usage in pre- and posttariff periods
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
the tariff switch.
SSG sends a normal Accounting-Stop packet, as in the
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 11 is used in authorization and reauthorization responses to send quota tokens
and the tariff switch time. Table 11 describes the VSA content.
Table 11
Content of VSA Used in Authorization/Reauthorization Response Packets
Subattribute
Attribute ID Vendor ID ID and Type
Attribute Name
Subattribute Data
26
Quota
Q—Control-Info code for prepaid quota.
9
253
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 12 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 12 describes the VSA content.
14
Configuring SSG Accounting
Information About SSG Accounting
Table 12
Content of VSA Used in Reauthorization Requests and Accounting Packets
Subattribute
Attribute ID Vendor ID ID and Type
Attribute Name
Subattribute Data
26
Quota
Q—Control-Info code for prepaid quota.
9
253
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).
15
Configuring SSG Accounting
Information About SSG Accounting
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 13 describes the
attributes contained in a response to a service reauthorization request.
Table 13
Attribute
ID
Contents of Service Reauthorization Response Packet
Vendor Subattribute Status
ID
ID
28
Attribute Name
Type
Optional
Idle-Timeout
Integer Idle Timeout
Quota
ASCII
string
QT seconds
ASCII
string
QX seconds;
bytes; bytes
26
9
253
Optional
26
9
253
Mandatory Quota-for-Tariff
Switching
Subattribute Data
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 14.
Note
In Table 14, 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 14
16
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
not covered by
idle-timeout equal
to or greater than 0
0 or >0
SSG closes or does not open the connection.
Configuring SSG Accounting
Information About SSG Accounting
Table 14
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 7 on page 10
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.
17
Configuring SSG Accounting
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.
How to Configure SSG Accounting
This section describes how to configure SSG accounting features and contains the following tasks:
•
Configuring SSG Accounting, page 18
•
Configuring SSG Broadcast Accounting, page 19
•
Configuring SSG Prepaid Features, page 20
•
Configuring Postpaid Tariff Switching for SSG, page 27
Configuring SSG Accounting
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
18
1.
ssg accounting [per-host] [per-service] [interval seconds]
2.
ssg accounting stop rate-limit [records]
Configuring SSG Accounting
How to Configure SSG Accounting
DETAILED STEPS
Step 1
Command or Action
Purpose
ssg accounting [per-host] [per-service]
[interval seconds]
Enables SSG accounting and specifies the interval at which
accounting updates are sent to the accounting server.
•
To enable the sending of per-host accounting records
only, use the per-host keyword.
•
To enable the sending of per-service accounting records
only, use the per-service keyword
Example:
Router(config)# ssg accounting per-host
interval 60
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
1.
aaa group server radius group-name
2.
server ip-address auth-port auth-port-number acct-port acct-port-number
3.
aaa group server radius group-name
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
19
Configuring SSG Accounting
How to Configure SSG Accounting
DETAILED STEPS
Step 1
Command or Action
Purpose
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
acct-port acct-port-number
Configures a server in the selected server group.
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
acct-port acct-port-number
Configures a server in the selected server group.
Example:
Router(config-sg)# server 10.10.50.180 auth-port
1812 acct-port 1813
Step 5
aaa accounting network accounting-list-name
start-stop broadcast group group-name group
group-name
Configures a broadcast accounting network list.
•
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
This section contains the following tasks:
•
Configuring SSG Prepaid Features on the Router, page 20
•
Configuring RADIUS Service Profiles for the SSG Prepaid Support Feature, page 22
•
Redirecting TCP Traffic for SSG Prepaid Quota Refill, page 22
•
Verifying Configuration of the SSG Prepaid Feature, page 24
Configuring SSG Prepaid Features on the Router
Perform this task to configure SSG prepaid features on the router.
20
Configuring SSG Accounting
How to Configure SSG Accounting
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.
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
SUMMARY STEPS
DETAILED STEPS
Step 1
Command or Action
Purpose
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
requests.
Example:
Router(config)# radius-server attribute 44
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
Example:
Router(config)# ssg aaa group prepaid
ssg_prepaid
(Optional) Specifies the server group to be used for SSG
prepaid authorization.
•
If the server group is not configured, SSG will send
prepaid requests to the local AAA server, which then
parses the prepaid authorizations and
reauthorizations.
21
Configuring SSG Accounting
How to Configure SSG Accounting
Step 4
Command or Action
Purpose
ssg prepaid threshold [time seconds]
(Optional) Sets the prepaid threshold time in seconds.
•
Example:
SSG performs a reauthorization when a user’s quota
reaches this threshold.
Router(config)# ssg prepaid threshold time 100
Step 5
ssg prepaid threshold [volume bytes]
Example:
(Optional) Sets the prepaid threshold volume in bytes.
SSG performs a reauthorization when a user’s quota
matches this byte value.
Router(config)# ssg prepaid threshold volume 100
Step 6
ssg prepaid threshold default-quota
[number-of-times]
(Optional) Specifies the number of times that SSG will
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
Step 8
radius-server vsa send authentication
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.
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.
22
Configuring SSG Accounting
How to Configure SSG Accounting
Prerequisites
The SESM Captive Portal feature must be configured on the appropriate port to listen for redirect
requests.
SUMMARY STEPS
1.
ssg tcp-redirect
2.
server-group group-name
3.
server ip-address port
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
Command or Action
Purpose
ssg tcp-redirect
Sets the server group and server used for quota refill
redirection.
Example:
Router(config)# ssg tcp-redirect
Step 2
server-group group-name
Example:
Router(config-ssg-redirect)# server-group
myserver group
Step 3
server ip-address port
Defines the group of one or more servers that make up a
named captive portal group and enters
SSG-redirect-group configuration mode.
•
Adds a server to a captive portal group.
•
ip-address—IP address of the server to add to the
captive portal group.
•
port—TCP port of the server to add to the captive
portal group.
Example:
Router(config-ssg-redirect-group)# server
192.168.10.10 port 1
group-name—Name of 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
Example:
Router(config-ssg-redirect)# redirect
prepaid-user to myserver
Configures a captive portal group for redirection of
prepaid user traffic.
•
server-group-name—Name of the captive portal
group.
23
Configuring SSG Accounting
How to Configure SSG Accounting
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
1.
show ssg connection ip-address service-name [interface]
2.
show ssg service [service-name [begin expression | exclude expression | include expression]]
3.
show ssg tcp-redirect group [group-name]
4.
show running-config
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
------------------------ConnectionObject Content ----------------------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
Connection Traffic Statistics:
Input Bytes = 4000, Input packets = 40
Output Bytes = 4000, Output packets = 40
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:
Router# show ssg connection 172.16.0.0 Internet
------------------------ConnectionObject Content ----------------------User Name:quser
Owner Host:172.16.0.0
Associated Service:Internet
Connection State:0 (UP)
Connection Started since:*02:29:09.000 GMT Thu Oct 9 2003
User last activity at:*02:30:14.000 GMT Thu Oct 9 2003
Connection Traffic Statistics:
Input Bytes = 0, Input packets = 0
Output Bytes = 0, Output packets = 0
Prepaid quota:
Quota Type = 'VOLUME', Quota Value = 0
Timeout Value = 0
Session policing disabled
24
Configuring SSG Accounting
How to Configure SSG Accounting
The following output is displayed when a user receives a time quota:
Router# show ssg connection 172.16.0.0 Internet
------------------------ConnectionObject Content ----------------------User Name:quser
Owner Host:172.16.0.0
Associated Service:Internet
Connection State:0 (UP)
Connection Started since:*02:35:51.000 GMT Thu Oct 9 2003
User last activity at:*02:35:51.000 GMT Thu Oct 9 2003
Connection Traffic Statistics:
Input Bytes = 0, Input packets = 0
Output Bytes = 0, Output packets = 0
Prepaid quota:
Quota Type = 'TIME', Quota Value = 30
Session policing disabled
The following output is displayed when a user receives a zero time quota with idle timeout:
Router# show ssg connection 172.16.0.0 Internet
------------------------ConnectionObject Content ----------------------User Name:quser
Owner Host:172.16.0.0
Associated Service:Internet
Connection State:0 (UP)
Connection Started since:*02:38:20.000 GMT Thu Oct 9 2003
User last activity at:*02:38:20.000 GMT Thu Oct 9 2003
Connection Traffic Statistics:
Input Bytes = 0, Input packets = 0
Output Bytes = 0, Output packets = 0
Prepaid quota:
Quota Type = 'TIME', Quota Value = 0
Timeout Value = 60
Session policing disabled
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
25
Configuring SSG Accounting
How to Configure SSG Accounting
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
Current TCP redirect groups:
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
.
.
.
26
Configuring SSG Accounting
How to Configure SSG Accounting
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 15 describes the contents
of this VSA.
Table 15
Post-Paid VSA Content
Subattribute
Attribute ID Vendor ID ID and Type
Attribute Name
Subattribute Data
26
post-paid
P—Service-Info code for postpaid
service.
9
251
Service-Info
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 15.
DETAILED STEPS
Step 1
Command or Action
Purpose
Add the Post-Paid VSA (attribute 26) to the service
profile using the parameters listed in Table 15.
Specifies the tariff switch points for postpaid tariff
switching.
27
Configuring SSG Accounting
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.:
SSG Service-Info = "PPW20:00:00:31"
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.:
SSG Service-Info = "PPW06:00:00:31"
Configuration Examples for SSG Accounting
This section contains the following examples:
•
Accounting Update Interval per Service in RADIUS: Example, page 28
•
Basic Prepaid Configuration: Examples, page 28
•
TCP Redirect for Prepaid Users: Example, page 29
•
Configuring Prepaid Threshold Value: Examples, page 29
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{
radius=7200-SSG-v1.1 {
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"
Basic Prepaid Configuration: Examples
The following example shows how to configure SSG to provide basic prepaid billing services:
28
Configuring SSG Accounting
Additional References
radius-server attribute 44 include-in-access-req
radius-server attribute 55 include-in-acct-req
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
Additional References
The following sections provide references related to the SSG Accounting feature.
29
Configuring SSG Accounting
Feature Information for SSG Accounting
Related Documents
Related Topic
Document Title
Configuring SESM
Cisco Subscriber Edge Services Manager documentation.
Configuring RADIUS
“Configuring RADIUS” chapter in the Cisco IOS Security Configuration Guide,
Release 12.4
Cisco IOS Security Command Reference, Release 12.4
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, 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.
Feature Information for SSG Accounting
Table 16 lists the features in this module and provides links to specific configuration information. Only
features that were introduced or modified in Cisco IOS Releases 12.2(4)B or later appear in the table.
Not all commands may be available in your Cisco IOS software release. For details on when support for
specific commands was introduced, see the command reference documents.
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.
30
Configuring SSG Accounting
Feature Information for SSG Accounting
Table 16
Feature Information for SSG Accounting
Feature Name
Extended Prepaid Tariff Switching for SSG
Software
Releases
12.3(14)T
12.4
Feature Configuration Information
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.
The following section provides information about this
feature:
•
Postpaid Tariff Switching for SSG
SSG Accounting
SSG Accounting Update Interval Per Service
12.2(16)B
12.3(4)T
12.3(14)T
12.4
12.0(3)DC
12.2(4)B
12.2(11)T
12.2(16)B
12.3(4)T
12.3(14)T
12.4
12.2(13)T
Extended Prepaid Tariff Switching for SSG, page 17
The Postpaid Tariff Switching for SSG feature allows
changes in tariffs during the lifetime of a connection.
The following section provides information about this
feature:
•
Postpaid Tariff Switching for SSG, page 17
•
Configuring Postpaid Tariff Switching for SSG,
page 27
The SSG Accounting feature allows a service provider to
decide how to configure billing and accounting for its users.
The following sections provide information about this
feature:
•
RADIUS Accounting Records Used by SSG, page 2
•
Types of SSG Accounting, page 4
•
Configuring SSG Accounting, page 18
The SSG Accounting Update Interval Per Service feature
allows the service provider to configure different
accounting intervals for different services.
The following sections provide information about this
feature:
SSG Default Quota for Prepaid Billing Server
Failure
12.3(11)T
•
SSG Accounting Update Interval per Service Feature,
page 5
•
Accounting Update Interval per Service in RADIUS:
Example, page 28
The SSG Default Quota for Prepaid Billing Server 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 12
•
Prepaid Tariff Switching, page 13
31
Configuring SSG Accounting
Feature Information for SSG Accounting
Table 16
Feature Information for SSG Accounting (continued)
Feature Name
SSG Prepaid Enhancements
Software
Releases
Feature Configuration Information
12.2(16)B
12.3(4)T
12.3(14)T
12.4
The SSG Prepaid Enhancements feature adds support for
prepaid tariff switching, postpaid tariff switching, and
simultaneous volume- and time-based prepaid billing to the
existing SSG Prepaid feature.
The following sections provide information about this
feature:
SSG Prepaid Idle Timeout
12.2T
12.3(4)T
•
SSG Prepaid Functionality, page 5
•
Prepaid Tariff Switching, page 13
•
Configuring SSG Prepaid Features, page 20
•
Basic Prepaid Configuration: Examples, page 28
•
TCP Redirect for Prepaid Users: Example, page 29
•
Configuring Prepaid Threshold Value: Examples,
page 29
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 following sections provide information about this
feature:
•
SSG Prepaid Tariff Switching
12.2(4)B
12.2(11)T
SSG Prepaid Idle Timeout, page 9
The SSG Prepaid Tariff Switching feature allows changes in
tariffs during the lifetime of a connection.
The following sections provide information about this
feature:
SSG Suppression of Unused Accounting Records 12.2T
12.3(4)T
•
SSG Prepaid Functionality, page 5
•
Prepaid Tariff Switching, page 13
•
Configuring SSG Prepaid Features, page 20
•
Basic Prepaid Configuration: Examples, page 28
•
TCP Redirect for Prepaid Users: Example, page 29
•
Configuring Prepaid Threshold Value: Examples,
page 29
The SSG Suppression of Unused Accounting Records
feature allows you to turn off unneeded Service Selection
Gateway (SSG) accounting records.
The following sections provide information about this
feature:
32
•
Types of SSG Accounting, page 4
•
Configuring SSG Accounting, page 18
Configuring SSG Accounting
Feature Information for SSG Accounting
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
33
Configuring SSG Accounting
Feature Information for SSG Accounting
34
RADIUS Profiles and Attributes for SSG
This module describes RADIUS profiles and their attributes.
Module History
This module was first published on May 2, 2005, and last updated on May 2, 2005.
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 RADIUS Profiles and Attributes for SSG” section
on page 57.
Contents
Prerequisites for RADIUS Profiles and Attributes for SSG, page 1
Information About RADIUS Profiles and Attributes for SSG, page 1
Additional References, page 56
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
This section describes the following concepts:
•
RADIUS Profiles for SSG Support, page 2
•
RADIUS Accounting Records for SSG, page 48
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
RADIUS Profiles for SSG Support
This section describes the following concepts:
•
SSG Vendor-Specific Attributes, page 2
•
Subscriber Profiles, page 29
•
Service Profiles, page 32
•
Service Group Profiles, page 41
•
Pseudo-Service Profiles, page 42
•
Examples of SSG RADIUS Profiles, page 45
SSG Vendor-Specific Attributes
Table 1 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 1
Vendor-Specific Attributes
AttributeID
VendorID
SubattributeID
SubattributeName
SubattributeDataType
26
9
1
Cisco-AVpair
Attributes
String
26
9
250
SSG Account-Info String
Attributes
26
9
251
SSG Service Info
Attributes
String
26
9
253
SSG Control Info
Attributes
String
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
.
Table 2
Cisco AV Pair Attributes
Attribute
Description
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
Control List
2
Specifies the secret (the password) used for L2TP tunnel authentication.
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
Table 2
Cisco AV Pair Attributes
Attribute
Description
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.
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 3
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.
3
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
Table 3
SSG Account Information Attributes
Subattribute Value
Attribute Function
Description
R
TCP Redirection
Specifies the TCP Redirection
configuration for the host
S
Subscriber IP
Identifies the host on SSG.
TP
Transparent Pass-through (TP)
Info
Specifies the Transparent pass-through
(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
+-+-+-+-+-+-+-+-+-+-+
4
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
|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 = '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 |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
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 = '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
5
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
|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 = '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 |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
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 = 'N' (account-info code for service name)
for account info reply:
g = <name;description;flag>
6
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
(the flag is 'P', 'X' or 'T' representing the service type)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
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 = '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 |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
7
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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 = '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 |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
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 = '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>]'
8
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
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 = '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 |
9
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
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 = '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 |
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
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 = '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
|
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
10
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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)
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 4 below.
Note
The host name, host IP address and host MSISDN will be sent using the standard RADIUS attributes.
Table 4
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
attribute #31 –
Calling-Station-ID
A string field containing the MSISDN of
a client. This attribute is only present for
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+
11
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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)
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 5.
Table 5
SSG Account Information Attributes
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
Address
IP
<servicename>;<real IP>
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.
12
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
Table 6
SSG Service Info Attributes
Subattribute Value
Attribute Function
Description
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
Proxy RADIUS
Specifies a cookie string fro a service.
X
Enable Full User Name for
Proxy RADIUS
Appends the service name to the
username during authentication to the
service.
13
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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|
+-+-+-+-+-+-+-+-+-+-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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
|
+-+-+-+-+-+-+-+-+-+-+-+-+...-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
f = 'B' (service-info code for MTU for SSG l2tp service)
g = <non-zero MTU as a string>
14
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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
|
+-+-+-+-+-+-+-+-+-+-+-+-+...-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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
|
+-+-+-+-+-+-+-+-+-+-+-+-+...-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
f = 'D' (service-info code for service DNS)
g = <ip1[;ip2]> (IP of the Primary/Secondary DNS servers in dot notation)
15
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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 |
+-+-+-+-+-+-+-+-+-+-+...-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS vendor-specific)
c = 9 (Cisco vendor ID)
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 |
+-+-+-+-+-+-+-+-+-+-+...-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS vendor-specific)
c = 9 (Cisco vendor ID)
d = 253 (subattribute ID for Service-Info)
e = len (length of the vendor-specific filter)
16
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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
|
+-+-+-+-+-+-+-+-+-+-+-+-+...-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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
|
+-+-+-+-+-+-+-+-+-+-+-+-+...-+
a = 26 (RADIUS attr for vendor specific)
17
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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
|
+-+-+-+-+-+-+-+-+-+-+-+-+....-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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
|
+-+-+-+-+-+-+-+-+-+-+-+-+...-+
18
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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|
+-+-+-+-+-+-+-+-+-+-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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
|
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
19
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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
|
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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|…|
+-+-+-+-+-+-+-+-+-+-+-+
a = 26 (RADIUS attr for vendor specific)
20
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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 |
+-+-+-+-+-+-+-+-+-+-+-....-+
a = 26 (RADIUS attr for vendor specific)
b = len(length of the RADIUS vendor-specific)
c = 9 (Cisco vendor ID)
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
21
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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
|
+-+-+-+-+-+-+-+-+-+-+-+-+....+-+-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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
|
+-+-+-+-+-+-+-+-+-+-+-+...-+
22
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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
|
+-+-+-+-+-+-+-+-+-+-+-+-+...-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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
+-+-+-+-+-+-+-+-+-+-+
23
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
|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 = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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|
+-+-+-+-+-+-+-+-+-+-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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'
24
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
len: >=4
+-+-+-+-+-+-+-+-+-+-+
|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 = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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|
+-+-+-+-+-+-+-+-+-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS Vendor specific Attribute>
c = 9 (Cisco vendor ID)
d = 251 (Subattribute ID for Service-Info)
e = len (length of the vendor specific subattribute)
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.
25
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
Table 7
SSG Control Info Attributes
Subattribute Value
Attribute Function
Description
F
Filter (that is, Port Filtering)
Currently not used by SSG.
F
Both Source and Destination
Filters (that is, Port Filtering)
Currently not used by SSG.
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 |
+-+-+-+-+-+-+-+-+-+-+...-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS vendor-specific)
c = 9 (Cisco vendor ID)
d = 253 (subattribute ID for Service-Info)
e = len (length of the vendor-specific filter)
p = 'F' (Port filter indication flag)
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
26
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
+-+-+-+-+-+-+-+-+-+-+...-+-+...-+
|a|b| c |d|e|f|p| g | h |
+-+-+-+-+-+-+-+-+-+-+...-+-+...-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS vendor-specific)
c = 9 (Cisco vendor ID)
d = 253 (subattribute ID for Service-Info)
e = len (length of the vendor-specific filter)
p = 'F' (Port filter indication flag)
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 |
+-+-+-+-+-+-+-+-+-+-+...-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS vendor-specific>
c = 9 (Cisco vendor ID)
d = 253 (subattribute ID for Service-Info)
e = len (length of the vendor-specific filter)
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)
27
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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 |
+-+-+-+-+-+-+-+-+-+-+...-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS vendor-specific>
c = 9 (Cisco vendor ID)
d = 253 (subattribute ID for Service-Info)
e = len (length of the vendor-specific filter)
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 |
+-+-+-+-+-+-+-+-+-+-+...-+
a = 26 (RADIUS attr for vendor specific)
b = len (length of the RADIUS vendor-specific>
c = 9 (Cisco vendor ID)
d = 253 (subattribute ID for Service-Info)
e = len (length of the vendor-specific filter)
p = 'O' (Output Bytes Count Flag)
g = <HI;LOW> (Formula to calculate exact byte count is HI*4294967296 + LOW)
28
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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 8 describes attributes that appear in RADIUS user profiles.
Table 8
Subscriber Profile Attributes
Attribute
Description
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.
29
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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.
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.
Example
Cisco-AVpair = "ip:outacl#101=deny tcp 192.168.1.0 0.0.0.255 any eq 21"
Multiple instances of the Downstream Access Control List attribute can occur within a single
profile. Use one attribute for each access control list statement. Multiple attributes can be used
for the same ACL. Multiple attributes are downloaded according to the number specified and are
executed in that order.
Note
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.
Cisco-AVpair = "ip:inacl[#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.
Example
Cisco-AVpair = "ip:inacl#101=deny tcp 192.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. Multiple attributes can be used
for the same ACL. Multiple attributes are downloaded according to the number specified and
executed in that order.
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]"
30
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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:
Note
•
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.
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.
31
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
Example
Account-Info = "GServiceGroup1"
Multiple instances of this attribute can occur within a user or service-group profile. Use one
attribute for each service subgroup.
Note
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.
RADIUS Freeware Format Example
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.
Downstream Access Control List
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
32
number
Access list identifier.
standard-access-control-list
Standard access control list.
extended-access-control-list
Extended access control list.
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
Example
Cisco-AVpair = "ip:outacl#101=deny tcp 192.168.1.0 0.0.0.255 any eq 21"
Multiple instances of the Downstream Access Control List attribute can occur within a single
profile. Use one attribute for each access control list statement. Multiple attributes can be used
for the same ACL. Multiple attributes are downloaded according to the number specified and are
executed in that order.
Note
Upstream Access Control List
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
number
Access list identifier.
standard-access-control-list
Standard access control list.
extended-access-control-list
Extended access control list.
Example
Cisco-AVpair = "ip:inacl#101=deny tcp 192.168.1.0 0.0.0.255 any eq 21"
Multiple instances of the Upstream Access Control List attribute can occur within a single
profile. Use one attribute for each access control list statement. Multiple attributes can be used
for the same ACL. Multiple attributes are downloaded according to the number specified and are
executed in that order.
Note
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.
33
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
Cisco-AVpair =
"vpdn:ip-addresses=address1[<delimiter>address2][<delimiter>address3]..."
Syntax Description
address
<delimiter>
IP address of the home gateway.
, (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).
RADIUS Freeware Format:: Example
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"
CiscoSecure ACS for UNIX: Example
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.
RADIUS Freeware Format:: Example
Cisco-AVpair = "vpdn:tunnel-id=My-Tunnel"
CiscoSecure ACS for UNIX: Example
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.
RADIUS Freeware Format:: Example
Cisco-AVpair = "vpdn:l2tp-hello-interval=2"
34
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
CiscoSecure ACS for UNIX: Example
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 9 shows the format of the Service-Info VSA needed to enable attribute filtering.
Table 9
SSG Service-Info VSA Descriptions
Attribute ID
Vendor ID
Subattribute ID Attribute Name
Subattribute Data
26
9
250
The value F is the filter indication flag
and should be set as F31.
Service-Info
Table 10 lists the attributes used for service logon with and without the MSISDN and with MSISDN
filter set to F31.
Table 10
Service Logon Comparison (With MSISDN, Without MSISDN, and With MSISDN
Filter)
Service
Logon
Connection
Authentication1
Connection
Accounting to
Local AAA
Without
MSISDN
Host Calling ID
Host Calling ID Host Calling ID Host Calling ID
Host Calling ID
Host Calling ID Connection
Calling ID
Host Calling ID
Host Calling ID
Host Calling ID Calling ID not
sent
Host Calling ID
Host Calling ID
With
Connection
MSISDN3 Calling ID
With
MSISDN
filter set
to F31
Calling ID not
sent
Connection
Accounting to
Remote AAA2
Prepaid
Prepaid
(Re)authorization Accounting
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.
35
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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
RADIUS Freeware Format Example
Service-Info = "X"
CiscoSecure ACS for UNIX Example
9,251 = "X"
36
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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
RADIUS Freeware Format Example
9,251 = "B1500"
CiscoSecure ACS for UNIX Example
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
s
IP address of the RADIUS server.
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.
37
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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:
•
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
RADIUS Freeware Format:: Example
Service-Info = "VserviceIDandAAA-ID"
CiscoSecure ACS for UNIX: Example
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
38
Description of the service.
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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.
39
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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:
Note
•
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.
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.
RADIUS Freeware Format Example
Service-Info = "TT"
CiscoSecure ACS for UNIX Example
9,251 = "TT"
40
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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 11 describes attributes that can be used in SSG service-group profiles.
Table 11
Service-Group Profile Attributes
Attribute
Description
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"
41
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
Syntax Description
name
Name of the group profile.
Example
Account-Info = "GServiceGroup1"
Multiple instances of the Service Group attribute can occur within a user or service-group
profile. Use one attribute for each service subgroup.
Note
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 12 lists the Cisco AVPair attributes that appear within transparent pass-through filter
pseudo-service profiles. The Cisco-AVpair attributes are used to configure ACLs.
Table 12
42
Transparent Pass-Through Filter Pseudo-Service Profile Attributes
Attribute
Description
Downstream Access Control List
(outacl)
Specifies either a Cisco IOS standard access control list or an
extended access control list to be applied to downstream traffic
going to the user.
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.
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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.
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.
Example
Cisco-AVpair = "ip:outacl#101=deny tcp 192.168.1.0 0.0.0.255 any eq 21"
Multiple instances of the Downstream Access Control List attribute can occur within a single
profile. Use one attribute for each access control list statement. Multiple attributes can be used
for the same ACL. Multiple attributes are downloaded according to the number specified and are
executed in that order.
Note
Upstream Access Control List
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.
Cisco-AVpair = "ip:inacl[#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.
Example
Cisco-AVpair = "ip:inacl#101=deny tcp 192.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. Multiple attributes can be used
for the same ACL. Multiple attributes are downloaded according to the number specified and are
executed in that order.
The Transparent Pass-Through Filter pseudo-service profile allows or denies access to IP addresses and
ports accessed through the transparent pass-through feature.
To define what traffic can pass through, SSG downloads the Transparent Pass-Through Filter
pseudo-service profile. This profile contains a list of ACL attributes. Each item contains an IP address
or range of IP addresses and a list of port numbers and specifies whether traffic is allowed or denied.
To create a filter for transparent pass-through, create a profile that contains ACL attributes that define
what can and cannot be accessed.
43
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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 13 describes the attribute that can be used in Next-Hop Gateway
pseudo-service profiles.
Table 13
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.
44
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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
Idle-Timeout
Service-Info
Service-Info
Service-Info
Service-Info
Service-Info
Service-Info
Service-Info
Service-Info
Service-Info
Password = "cisco", Service-Type = outbound,
= 1800,
= "R192.168.1.128;255.255.255.192",
= "R192.168.2.0;255.255.255.192",
= "R192.168.3.0;255.255.255.0",
= "Gservice1",
= "D192.168.2.81",
= "MC",
= "TP",
= "ICompany Intranet Access",
= "Oservice1.com"
Service Profile Formatted for use with a Freeware RADIUS Server Formatted for CiscoSecure ACS for UNIX:
Example
The following is the same profile as above, formatted for CiscoSecure ACS for UNIX:
user = service1.com {
radius = SSG {
check_items = {
2 = "cisco"
6 = 5
}
reply_attributes = {
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"
45
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
9,251
9,251
9,251
9,251
9,251
}
=
=
=
=
=
"D192.168.2.81"
"MC"
"TP"
"ICompany Intranet Access"
“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
Account-Info =
Account-Info =
Account-Info =
Account-Info =
Account-Info =
Password = "cisco", Service-Type = outbound,
"Nservice1.com",
"Ngamers.net",
"GServiceGroup3",
"GServiceGroup4",
"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
reply_attributes = {
9,250 = "Nservice1.com"
9,250 = "Ngamers.net"
9,250 = "GServiceGroup3"
9,250 = "GServiceGroup4"
46
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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"
The following is the same profile as above, formatted for CiscoSecure ACS for UNIX:
user = ssg-filter {
radius = SSG {
check_items = {
2 = "cisco"
6 = 5
reply_attributes = {
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
Account-Info
Account-Info
Account-Info
Account-Info
Account-Info
=
=
=
=
=
Password = "cisco", Service-Type = outbound,
"Gservice3;192.168.103.3",
"Gservice2;192.168.103.2",
"Gservice1;192.168.103.1",
"GLabservices;192.168.4.2",
"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"
}
}
47
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
RADIUS Accounting Records for SSG
This section describes the following concepts:
Note
•
Account Logon, page 48
•
Account Logoff, page 48
•
Connection Start, page 49
•
Connection Stop, page 50
•
Attributes Used in Accounting Records, page 52
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:
Acct-Status-Type = Start
NAS-IP-Address = ip_address
User-Name = "username"
Acct-Session-Id = "session_id"
Framed-IP-Address = user_ip
Proxy-State = "n"
Table 14 describes the attributes shown in the display.
Table 14
Account Logon Accounting Record Attributes
Attribute
Description
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:
Acct-Status-Type = Stop
NAS-IP-Address = ip_address
48
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
User-Name = "username"
Acct-Session-Time = time
Acct-Terminate-Cause = cause
Acct-Session-Id = "session_id"
Framed-IP-Address = user_ip
Proxy-State = "n"
Table 15 describes the attributes shown in the display.
Table 15
Account Logoff Accounting Record Attributes
Attribute
Description
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-Time
Length of session, in seconds.
Acct-Terminate-Cause
Cause of account termination:
•
User-Request
•
Session-Timeout
•
Idle-Timeout
•
Lost-Carrier
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).
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-IP-Address = 172.16.6.1
NAS-Port = 0
NAS-Port-Type = Virtual
User-Name = "username"
Acct-Status-Type = Start
Acct-Authentic = RADIUS
Service-Type = Framed
Acct-Session-Id = "00000010"
Framed-Protocol = PPP
Service-Info = "Nisp-name.com"
Service-Info = "Uusername"
Service-Info = "TP"
Acct-Delay-Time = 0
49
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
Table 16 describes the attributes shown in the display.
Table 16
Connection Start Accounting Record Attributes
Attribute
Description
NAS-IP-Address
IP address of SSG.
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.
User-Name
Name used to log on to the service provider network.
Acct-Status-Type
Indicates whether this Accounting-Request marks the beginning of
the user service (start) or the end (stop).
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”.
Acct-Session-Id
Session number.
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.
Acct-Delay-Time
•
P—Pass-through (usually the Internet)
•
T—Tunnel
•
X—Proxy
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-IP-Address = 192.168.2.48
NAS-Port = 0
NAS-Port-Type = Virtual
User-Name = "zeus"
Acct-Status-Type = Stop
Service-Type = Framed-User
Acct-Session-Id = "00000002"
Acct-Terminate-Cause = User-Request
Acct-Session-Time = 84
Acct-Input-Octets = 0
Acct-Output-Octets = 649
Acct-Input-Packets = 0
Acct-Output-Packets = 17
50
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
Framed-Protocol = PPP
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 17 describes the attributes shown in the display.
Table 17
Connection Stop Accounting Record Attributes
Attribute
Description
NAS-IP-Address
IP address of SSG.
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.
User-Name
Name used to log on to the service provider network.
Acct-Status-Type
Indicates whether this Accounting-Request marks the beginning of
the user service (start) or the end (stop).
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-Session-Id
Session number.
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.
Framed-IP-Address
IP address of the user’s system.
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.
51
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
Table 17
Connection Stop Accounting Record Attributes (continued)
Attribute
Description
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.
Acct-Delay-Time
•
P—Pass-through (usually the Internet)
•
T—Tunnel
•
X—Proxy
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 = "[email protected]"
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"
52
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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.
53
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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:
•
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
Configuration Examples for SSG Full Username RADIUS Attribute
RADIUS Freeware Format: Example
Service-Info = “X”
CiscoSecure ACS for UNIX: Example
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
54
RADIUS Profiles and Attributes for SSG
Information About RADIUS Profiles and Attributes for SSG
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 18.
55
RADIUS Profiles and Attributes for SSG
Additional References
Table 18
NAS-Port Accounting Record Attributes
Attribute
Description
NAS-Port
Physical port number of the network access server that is
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:
NAS-Port-Type
•
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.
Type of physical port that the network access server is using to
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
Additional References
The following sections provide references related to RADIUS Profiles and Attributes for SSG.
56
RADIUS Profiles and Attributes for SSG
Feature Information for RADIUS Profiles and Attributes for SSG
Related Documents
Related Topic
Document Title
SSG commands
Cisco IOS Service Selection Gateway Command Reference,
Release 12.4
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
Configuration Guide, Release 12.4
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,
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.
http://www.cisco.com/public/support/tac/home.shtml
Feature Information for RADIUS Profiles and Attributes for SSG
Table 19 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.0(3)DC 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.
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.
Note
Table 19 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.
57
RADIUS Profiles and Attributes for SSG
Feature Information for RADIUS Profiles and Attributes for SSG
Table 19
Feature Information for RADIUS Profiles and Attributes for SSG
Feature Name
Releases
Feature Configuration Information
RADIUS Profiles and Attributes for SSG
12.0(3)DC
12.2(4)B
12.2(11)T
12.2(13)T
12.3(4)T
12.3(7)T
12.3(14)T
12.4
SSG uses RADIUS Profiles and attributes for the
authentication, authorization, and accounting of
subscribers.
The following sections provide information about this
feature:
•
RADIUS Profiles for SSG Support, page 2
•
SSG Vendor-Specific Attributes, page 2
•
Subscriber Profiles, page 29
•
Service Profiles, page 32
•
Service Group Profiles, page 41
•
Pseudo-Service Profiles, page 42
•
Examples of SSG RADIUS Profiles, page 45
•
RADIUS Accounting Records for SSG, page 48
•
Attributes Used in Accounting Records, page 52
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2007 Cisco Systems, Inc. All rights reserved.
58
SSG Mobile Wireless Enhancements
First Published: November 5, 2007
Last Updated: November 5, 2007
The Service Selection Gateway (SSG) is a Cisco IOS software feature set, supported on multiple
platforms, that works with the Cisco Subscriber Edge Services Manager (SESM) and other components
to provide a subscriber edge services solution. It implements Layer 3 service selection through selective
routing of IP packets to destination networks on a per subscriber basis. SSG authenticates users, who are
accessing the SSG services, based on the RADIUS access request received from the SESM or from the
downstream device such as a Gateway GPRS Support Node (GGSN) or Packet Data Serving Node
(PDSN).
The SSG Mobile Wireless Enhancements feature describes additional functionality enhancements
including accounting-on-off packet suppression, accounting-start ignore configuration, and Packet of
Disconnect (PoD) forwarding to the Network Access Server (NAS).
Finding Feature Information in This Module
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 SSG Mobile Wireless Enhancements” section on page 8.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS
software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An
account on Cisco.com is not required.
Contents
•
Prerequisites for SSG Mobile Wireless Enhancements, page 2
•
Restrictions for SSG Mobile Wireless Enhancements, page 2
•
Information About SSG Mobile Wireless Enhancements, page 2
•
How to Configure SSG Mobile Wireless Enhancements, page 4
•
Configuration Examples for SSG Mobile Wireless Enhancements, page 6
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2008 Cisco Systems, Inc. All rights reserved.
SSG Mobile Wireless Enhancements
Prerequisites for SSG Mobile Wireless Enhancements
•
Additional References, page 7
•
Command Reference, page 8
•
Feature Information for SSG Mobile Wireless Enhancements, page 8
Prerequisites for SSG Mobile Wireless Enhancements
•
Before implementing SSG Mobile Wireless enhancements, SSG must be enabled by using the ssg
enable command.
•
This enhancement supports General Packet Radio Service/Extensible Authentication Protocol
(GPRS/EAP) for the SSG. You should understand the following technologies:
– The Serving GPRS Support Node (SGSN) connects the radio access network (RAN) to the
GPRS and the 3G Universal Mobile Telecommunication System (UMTS) core and tunnels user
sessions to the GGSN. For more information, see Cisco GGSN Release 7.0 Configuration
Guide.
– The SSG EAP Transparency feature enables SSG on a Cisco router to act as a RADIUS proxy
during EAP authentication and to create the host. For more information, see the SSG EAP
Transparency feature module.
– The Access Zone Router (AZR) provides connectivity, client address management, security
services, and routing across a WAN from each access point to an operator’s point of presence
(POP) or data center. For more information, see the Public Wireless LAN for Service Providers
Solutions document.
Restrictions for SSG Mobile Wireless Enhancements
SSG does not process multicast packets.
Information About SSG Mobile Wireless Enhancements
To implement SSG Mobile Wireless enhancements, you should understand the following concepts:
•
Accounting-On-Off Packet Suppression, page 2
•
Accounting-Start Packet Discards to Retain a Host with Varying IP Addresses, page 3
•
PoD to NAS Forwarding, page 3
Accounting-On-Off Packet Suppression
While SSG is acting as a RADIUS proxy for the Gateway GPRS Support Node (GGSN), it also receives
all accounting packets: accounting-on-off packets as well as accounting-start-stop packets. By default,
only accounting-on-off packets are forwarded to the real authentication, authorization, and accounting
(AAA) server.
The forward accounting-on-off command allows you to override this default behavior and to suppress
transparent proxying of accounting packets.
2
SSG Mobile Wireless Enhancements
Information About SSG Mobile Wireless Enhancements
SSG always proxies accounting-on-off packets received from client GGSNs. These packets 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. SSG uses the NAS IP address in the accounting-on-off packets to determine the affected GGSN.
Determining the affected GGSN enables multiple tunnel interfaces to exist between the GGSN and SSG.
Although there are multiple RADIUS clients configured at SSG, only a single accounting-on-off packet
is generated by the GGSN. As part of the normal SSG functionality, SSG sends accounting-start-stop
records for both the active host objects and for any services to which they are connected.
Consider the following scenario in a load-balancing environment. Assume that there are 10 GGSNs and
10 SSGs in the system. In this case, when the GGSN fails, there will be 10 accounting-off packets sent
to the RADIUS load balancing (RLB) server farm. The RLB server farm replicates each accounting-off
packet to the 10 SSGs. Each SSG in turn forwards these accounting-off packets to the AAA server. So
there is a total of 100 accounting-off packets in a short period of time. For some customers the AAA
server often has problems handling this high rate of accounting on and off packets, which increases the
possibility of a system failure.
In a Cisco Mobile Exchange (CMX) solution, you can enable a server to stop forwarding the
accounting-off packets in all the routers except for two or three routers. Enabling the server in this way
ensures that the AAA server will not receive the accounting-off packets from every SSG in the system.
Accounting-Start Packet Discards to Retain a Host with Varying IP Addresses
Before Cisco IOS Release 12.4(15)T, the default behavior of the session-identifier msid command for
SSG is to disconnect a host object if a second accounting-start packet is received for a Mobile Station
Identifier (MSID) address with a different IP address. However, this behavior can cause a problem
especially in the Public Wireless Local Area Network (PWLAN) space for clients with multiple
interfaces (that is, wireless and Ethernet interfaces), which can result in packets sent from a single
interface with multiple source IP addresses.
This enhancement to the session-identifier msid unique ip command instructs SSG to discard the
subsequent accounting-start records with the same MSID but a different IP address.
PoD to NAS Forwarding
When SSG, acting as a RADIUS proxy, receives the Packet of Disconnect (PoD) from a RADIUS server,
it cleans up the corresponding host object but does not forward the PoD to NAS. As a result, the NAS is
not informed about the RADIUS server’s decision to disconnect the user session.
This enhancement disconnects the host object when the PoD is received from the AAA server and also
forwards it to a downstream device. When SSG forwards the PoD to the downstream NAS, the NAS will
send a PoD-ACK/NAK back to SSG. Previously, SSG would have deleted the host object for that
particular user at this point. Therefore, this enhancement ensures that SSG ignores the PoD-ACK/NAKs
and accounting-stop packets sent by the NAS in response to the forwarded PoD.
On receiving the POD request with radius code 40, SSG disconnects the user by deleting all host-related
information maintained by SSG. The following points summarize the PoD support by SSG:
•
The host is identified by the following properties:
– Attribute 8: framed IP address
– SSG account-info VSA: port bundle information present with S subattribute
•
On finding the host, SSG deletes the host and connections made by the host.
3
SSG Mobile Wireless Enhancements
How to Configure SSG Mobile Wireless Enhancements
•
For a transparent autologon (TAL) user with no host object (a Transparent Passthrough [TP] user),
the TP entry will be deleted.
•
Inactive hosts will not be deleted.
•
In radius-proxy mode, SSG deletes the host object, but PoD will not be forwarded to the downstream
device. To clean up the session throughout the network, the AAA server will now send the PoD to
downstream devices.
How to Configure SSG Mobile Wireless Enhancements
This section contains the following procedures:
•
Suppressing Accounting On-Off Packets, page 4 (optional)
•
Retaining a Host with Varying IP Addresses by Ignoring Accounting-Start Packets, page 5
(optional)
Suppressing Accounting On-Off Packets
Perform this task to configure SSG to suppress accounting-on-off packets.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
ssg enable
4.
ssg radius-proxy
5.
no forward accounting-on-off
DETAILED STEPS
Step 1
Command or Action
Purpose
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
ssg enable
Example:
Router(config)# ssg enable
4
Enables SSG.
SSG Mobile Wireless Enhancements
How to Configure SSG Mobile Wireless Enhancements
Step 4
Command or Action
Purpose
ssg radius-proxy
Enables SSG RADIUS proxy.
Example:
Router(config)# ssg radius-proxy
Step 5
no forward accounting-on-off
Suppresses the forwarding of accounting-on-off packets.
Example:
Router(config-radius-proxy)# no forward
accounting-on-off
Retaining a Host with Varying IP Addresses by Ignoring Accounting-Start
Packets
Perform this task to configure SSG to enable client devices with multiple IP addresses to access the host.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
ssg enable
4.
ssg radius-proxy
5.
client-address ip-address
6.
key secret
7.
session-identifier msid unique ip
DETAILED STEPS
Step 1
Command or Action
Purpose
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
ssg enable
Enables SSG.
Example:
Router(config)# ssg enable
5
SSG Mobile Wireless Enhancements
Configuration Examples for SSG Mobile Wireless Enhancements
Step 4
Command or Action
Purpose
ssg radius-proxy
Enables SSG RADIUS proxy.
Example:
Router(config)# ssg radius-proxy
Step 5
client address ip-address
Specifies the IP address of the RADIUS client.
Example:
Router(config-radius-proxy)# client-address
172.16.1.1
Step 6
Specifies the key shared with the RADIUS client.
key secret
Example:
Router(config-radproxy-client)# key cisco
Step 7
session-identifier msid unique ip
Specifies the attribute for differentiating sessions.
Example:
This example uses the MSID as session differentiator and
its associated IP address.
Router(config-radproxy-client)#
session-identifier msid unique ip
Configuration Examples for SSG Mobile Wireless
Enhancements
This section provides the following configuration examples:
•
Suppressing Accounting On-Off Packets: Example, page 6
•
Retaining a Host with Varying IP Addresses by Ignoring Accounting-Start Packets: Example, page 6
Suppressing Accounting On-Off Packets: Example
The following example shows how to suppress packet forwarding from the RADIUS client to the AAA
server:
enable
configure terminal
ssg enable
ssg radius-proxy
no forward accounting-on-off
Retaining a Host with Varying IP Addresses by Ignoring Accounting-Start
Packets: Example
The following example shows how to configure SSG to identify the specified client session based on the
IP address associated with the MSID:
enable
configure terminal
6
SSG Mobile Wireless Enhancements
Additional References
ssg enable
ssg radius-proxy
client-address 172.16.1.1
key cisco
session-identifier msid unique ip
Additional References
The following sections provide references related to the SSG Mobile Wireless Enhancements feature.
Related Documents
Related Topic
Document Title
Selection Gateway commands: complete command
syntax, command mode, command history, defaults,
usage guidelines, and example
Cisco IOS Service Selection Gateway Command Reference,
Release 12.4
SSG configuration tasks
Cisco IOS Service Selection Gateway Configuration Guide,
Release 12.4
Cisco Express Forwarding Overview chapter in the Cisco IOS
Switching Services Configuration Guide, Release 12.0
SSG AutoDomain feature module, Release 12.2(4)B
SSG EAP Transparency feature module, Release 12.3(4)T
Standards
Standard
Title
—
No new or modified standards are supported by this
feature, and support for existing standards has not been
modified by this feature.
MIBs
MIB
MIBs Link
No new or modified MIBs are supported by this
feature, and support for existing MIBs has not been
modified by this feature.
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
7
SSG Mobile Wireless Enhancements
Command Reference
RFCs
RFC
Title
RFC 2284
PPP Extensible Authentication Protocol (EAP)
RFC 2865
Remote Authentication Dial-In User Services (RADIUS)
RFC 2869
RADIUS Delegated-IPv6-Prefix Attribute
RFC 2548
Microsoft Vendor-Specific RADIUS Attributes
Technical Assistance
Description
Link
http://www.cisco.com/techsupport
The Cisco Support website provides extensive online resources, including
documentation and tools for troubleshooting and resolving technical issues with Cisco
products and technologies.
To receive security and technical information about your products, you can subscribe to
various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco
Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website requires a Cisco.com user ID and
password.
Command Reference
The following commands are introduced or modified in the feature or features documented in this
module. For information about these commands, see the Cisco IOS Service Selection Gateway Command
Reference at http://www.cisco.com/en/US/docs/ios/ssg/command/reference/ssg_book.html. For
information about all Cisco IOS commands, go to the Command Lookup Tool at
http://tools.cisco.com/Support/CLILookup or to the Cisco IOS Master Commands List.
•
forward accounting-on-off
•
session-identifier
Feature Information for SSG Mobile Wireless Enhancements
Table 1 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a
specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support.
Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images
support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to
http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
8
SSG Mobile Wireless Enhancements
Feature Information for SSG Mobile Wireless Enhancements
Note
Table 1
Table 1 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.
Feature Information for SSG Mobile Wireless Enhancements
Feature Name
Releases
Feature Information
SSG Mobile Wireless Enhancements
12.4(15)T
SSG is a Cisco IOS software feature set, supported on multiple
platforms, that works with the Cisco SESM and other components to
provide a subscriber edge services solution. It implements Layer 3
service selection through selective routing of IP packets to
destination networks on a per subscriber basis. SSG authenticates
users, who are accessing the SSG services, based on the RADIUS
access request received from the SESM or from the downstream
device such as GGSN/PDSN.
The SSG Mobile Wireless Enhancements feature describes
additional functionality enhancements including accounting-on-off
suppression, accounting-start ignore configuration, and Packet of
Disconnect (PoD) forwarding to the Network Access Server (NAS).
The following commands were introduced or modified by this
feature: forward accounting-on-off, session-identifier.
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, 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, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, 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. (0711R)
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.
© 2008 Cisco Systems, Inc. All rights reserved.
9
SSG Mobile Wireless Enhancements
Feature Information for SSG Mobile Wireless Enhancements
10
