Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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