Cisco Scms SM Legs User Guide: Release 3.1.6 May 2008

Cisco SCMS SM LEGs User Guide
Release 3.1.6
May 2008
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
Customer Order Number:

Text Part Number: OL-15752-01
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT
SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE
OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public
domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH
ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO
OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco StadiumVision, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work,
Live, Play, and Learn is a service mark; 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, 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. (0804R)
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.
C O N T E N T S
Preface xi
CHAPTER 1 Terms and Concepts 1-1
General Concepts 1-1

Cable/Satellite Modem 1-1
CPE (Customer Premise Equipment) 1-1
LEG (Login Event Generator) 1-2
Pull-request 1-2
RDR (Raw Data Record) 1-2
Subscriber Domain 1-2
Subscriber ID 1-2
Subscriber Mappings 1-2
CNR Concepts 1-3
Communication Link Failure Handling 1-3
DHCP DoS Attack Filter 1-3
Remote Procedure Call Protocol (PRPC) 1-3
SM C++ API 1-3
SM Cable Support Module 1-4
Subscriber Autologout 1-4
Subscriber Mode 1-4
DHCP Concepts 1-4
DHCP ACK Packet 1-4
DHCP Lease Extension Transaction (Renewal) 1-5
DHCP Lease Query Transaction 1-5
DHCP Release Transaction 1-5
DHCP Sniffer 1-5
Subscriber Policy 1-5
RADIUS Concepts 1-5
NAS (Network Access System) 1-6
RADIUS Accounting Transactions 1-6
RADIUS Accounting Start/Interim/Stop 1-6
RADIUS Authentication Transactions 1-6
RADIUS Sniffer 1-6
Subscriber Mappings over VPN 1-6
Subscriber Policy 1-7

OL-15752-01 i
Contents
MPLS/VPN BGP Concepts 1-7

BGP (Border Gateway Protocol) 1-7
CE (Customer Edge) 1-7
MPLS (Multi Protocol Label Switching) 1-8
PE (Provider Edge) 1-8
RD (Route Distinguisher) 1-8
RR (Route Reflector) 1-8
RT (Route Target) 1-8
VPN ID 1-8
VPN (Virtual Private Networking) 1-8
VRF (Virtual Routing and Forwarding) 1-9
SOAP Concepts 1-9
SOAP 1-9
UsernameToken Profile 1-9
WSDL 1-9
WSS 1-9
PART 1 CNR LEG
CHAPTER 2 About the CNR LEG 2-1
The CNR LEG Module 2-1
CHAPTER 3 Installing the CNR LEG 3-1
Prerequisites 3-1
Package Contents 3-1
Installing the CNR LEG on Windows 3-2
Installing the CNR LEG on Solaris 3-3

Uninstalling the CNR LEG 3-4
CHAPTER 4 Configuring the CNR LEG and the SM 4-1
Information About Configuring the CNR LEG 4-1

Information About Setting the SM IP Address and Port 4-1
Setting the SM IP Address and Port 4-1
SM IP Address and Port Example 4-2
Information About Setting the Subscriber Mode 4-2
Setting the Subscriber Mode 4-2
Subscriber Mode Example 4-2
Information About Setting the Attack Filter Parameters 4-2

ii OL-15752-01
Contents
Setting the Attack Filter Parameters 4-3

Attack Filter Example 4-3
Information About Setting the Lease Time Option 4-3
Setting the Lease Time Option 4-3
Lease Time Option Example 4-4
Information About Configuring the Subscriber Manager 4-4
Information About Configuring SM-LEG Failure Handling 4-4
Information About Activating SM-LEG Failure Handling 4-4
Information About Setting LEG-Domains Associations 4-5
Information About Setting Domain Aliases 4-5
Setting Domain Aliases 4-6
Domain Aliases Example 4-6
Information About Configuring Autologout 4-6
Configuring Autologout 4-7
Autologout Example 4-7
Configuring the PRPC Server 4-7
CHAPTER 5 CNR Log Messages 5-1
Log Messages 5-1
CHAPTER 6 CNR LEG Functional Specification 6-1
CNR LEG High Level Design 6-1
Logging and Tracing 6-2
Extensions Point Operation 6-2

init-entry 6-3
post-send-packet 6-3
post-packet-decode 6-3
PART 2 DHCP Lease Query LEG
CHAPTER 7 About the DHCP Lease Query LEG 7-1
Information About the DHCP Lease Query LEG 7-1

DHCP Lease Query LEG Operation 7-1
Information About DHCP Lease Query LEG Functionality 7-3
DHCP Lease Query LEG Process 7-3
DHCP Lease Query Transaction 7-3
Installation and Usage 7-4

OL-15752-01 iii
Contents
CHAPTER 8 Subscriber Manager Integration 8-1
Installing the DHCP Lease Query LEG on the SM 8-1
Uninstalling the DHCP Lease Query LEG from the SM Server 8-2
Upgrading the DHCP Lease Query LEG 8-2
CHAPTER 9 Subscriber Manager Integration - Configuration 9-1
Information About Configuring the DHCP Lease Query LEG 9-1

Configuring the DHCP Lease Query LEG 9-1
Configuring Policy Association 9-4
Dynamic Assignment of Policy Information 9-4
Dynamic Assignment of Policy Information Example 9-6
Static Assignment of Policy Information 9-7
Information About the DHCP Lease Query LEG CLU 9-7
Viewing the DHCP Lease Query LEG Status 9-7
Viewing the DHCP Lease Query LEG Statistics 9-8
Viewing the DHCP Lease Query LEG Version 9-8
CHAPTER 10 SCE Integration 10-1
Installing the DHCP Lease Query LEG on the SCE 10-1
Uninstalling the DHCP Lease Query LEG from the SCE Device 10-1
Upgrading the DHCP Lease Query LEG 10-2
CHAPTER 11 SCE Integration - Configuration 11-1
Configuring the DHCP Lease Query LEG on the SCE 11-1
Information About the DHCP Lease Query LEG CLI 11-1

Configuration CLI 11-1
Show CLI 11-2
CHAPTER 12 DHCP Forwarder Application 12-1
Installing the DHCP Forwarder 12-1
Uninstalling the DHCP Forwarder 12-2
DHCP Forwarder VCS Agent 12-2

Adding a DHCP Forwarder Resource 12-2
Removing a DHCP Forwarder Resource 12-4
PART 3 SCE-Sniffer DHCP LEG

iv OL-15752-01
Contents
CHAPTER 13 About the SCE-Sniffer DHCP LEG 13-1
Information About the SCE-Sniffer DHCP LEG 13-1

SCE-Sniffer DHCP LEG Operation 13-1
Information About SCE-Sniffer DHCP LEG Functionality 13-2
DHCP Initial Logon Transaction 13-2
DHCP Lease Extension Transaction 13-3
DHCP Release Transaction 13-3
CHAPTER 14 Installing the SCE-Sniffer DHCP LEG 14-1
Installing the SCE-Sniffer DHCP LEG 14-1

Prerequisites 14-1
Uninstalling the SCE-Sniffer DHCP LEG 14-2
Upgrading the SCE-Sniffer DHCP LEG 14-2
CHAPTER 15 Configuring the SCE-Sniffer DHCP LEG 15-1
Information About Configuring the SCE-Sniffer DHCP LEG 15-1

Configuring the General Settings 15-1
Configuring Policy Association 15-3
Dynamic Assignment of Policy Information 15-3
Dynamic Assignment of Policy Information Example 15-5
Static Assignment of Policy Information 15-6
CHAPTER 16 Using the SCE-Sniffer DHCP LEG CLU 16-1
Information About the SCE-Sniffer DHCP LEG CLU 16-1

Viewing the SCE-Sniffer DHCP LEG Status 16-1
Viewing the SCE-Sniffer DHCP LEG Statistics 16-2
Viewing the SCE-Sniffer DHCP LEG Version 16-2
PART 4 RADIUS Listener LEG
CHAPTER 17 About the RADIUS Listener LEG 17-1
About the RADIUS Listener LEG 17-1
Topologies 17-2
CHAPTER 18 Installing the RADIUS Listener LEG 18-1
Installing the RADIUS Listener LEG Software 18-1
Uninstalling the RADIUS Listener LEG 18-2

OL-15752-01 v
Contents
CHAPTER 19 Configuring the RADIUS Listener LEG 19-1

[Radius Listener] Section 19-1
Example 19-2
Information About the Regular Expression Utility 19-2
Supported Syntax 19-2
Unsupported Syntax 19-4
Regular Expression Examples 19-4
Regular Expression Processing versus RADIUS Listener Login Rate 19-5
Configuring RADIUS Attributes Mapping 19-6

Mapping of RADIUS Attribute to Subscriber ID 19-6
Validation Rules 19-8
Configuring the Subscriber ID Example 19-8
Configuring the Vendor Specific Attribute (VSA) as Subscriber ID Example 19-8
Configuring Stripping of the Attribute Value Example using Regular Expression Rule 19-8
Mapping of RADIUS Attribute to Subscriber Policy 19-9
Extracting Data from a RADIUS Attribute 19-9
Validation Rules 19-10
Extracting Data from a RADIUS Attribute Example 19-10
Not Setting Any Policy to the Subscriber 19-11
Mapping of RADIUS Attribute to Subscriber IP Address 19-11
Configuring Subscriber IP Address Example 19-12
Configuring Subscriber IP Address over VPN Example 19-13
Configuring the NAS Devices 19-13
Configuring the NAS Devices: Example 19-14
CHAPTER 20 Configuring the RADIUS Client 20-1
Configuring the RADIUS Client 20-1
CHAPTER 21 Using the RADIUS Listener LEG CLU 21-1
Information About the p3radius Utility 21-1

Viewing the RADIUS Listener LEG Status 21-3
Viewing the RADIUS Listener LEG Statistics 21-4
Testing a Section in a Configuration File 21-4
Testing a Reduction Rule 21-5
Testing a Matching Rule 21-5

vi OL-15752-01
Contents
CHAPTER 22 Domain Association Algorithm 22-1
Domain Association Algorithm 22-1
PART 5 SCE-Sniffer RADIUS LEG
CHAPTER 23 About the SCE-Sniffer RADIUS LEG 23-1
Information About the SCE-Sniffer RADIUS LEG 23-1

RADIUS Integration Overview 23-2
CHAPTER 24 SCE-Sniffer RADIUS LEG Functionality 24-1
SCE-Sniffer RADIUS Functionality 24-1
Information About RADIUS Attributes 24-2

Subscriber ID Association 24-2
Domain Association 24-2
Policy Association 24-3
Subscriber IP Association 24-3
Information About RADIUS Packets 24-4
Accounting-Start Packet 24-4
Accounting-Interim-Update Packet 24-4
Accounting-Stop Packet 24-5
Access-Accept Packet 24-5
CHAPTER 25 Installing the SCE-Sniffer RADIUS LEG 25-1
Installing the SCE-Sniffer RADIUS LEG Software 25-1
Uninstalling the SCE-Sniffer RADIUS LEG 25-2
Upgrading the SCE-Sniffer RADIUS LEG 25-2
CHAPTER 26 Configuring the SCE-Sniffer RADIUS LEG 26-1
Configuring the Subscriber ID 26-2
Information About Configuring the Subscriber IP Address 26-3

Subscriber IP Address Configuration Example 26-3
Information About Configuring the Policy Settings 26-4
Policy Configuration Example 26-5
CHAPTER 27 Using the SCE-Sniffer RADIUS LEG CLU 27-1
Information About the SCE-Sniffer RADIUS LEG Utility 27-1

OL-15752-01 vii
Contents
Viewing the SCE-Sniffer RADIUS LEG Status 27-1

Viewing the SCE-Sniffer RADIUS LEG Version 27-2
Viewing the SCE-Sniffer RADIUS LEG Statistics 27-2
PART 6 MPLS/VPN BGP LEG
CHAPTER 28 About the MPLS/VPN BGP LEG 28-1
MPLS/VPN Overview 28-1
MPLS/VPN BGP LEG Overview 28-2

VPN Entity 28-3
VPN Identifier (RD or RT) 28-4
BGP LEG Scenario 28-4
CE as Subscriber 28-5
CHAPTER 29 Installing the MPLS/VPN BGP LEG 29-1
Installing the MPLS/VPN BGP LEG Software 29-2
Adding a VCS Resource to the BGP LEG 29-2
Removing a VCS Resource from the BGP LEG 29-3
CHAPTER 30 Configuring the MPLS/VPN BGP LEG 30-1
Configuring the MPLS/VPN BGP LEG Settings 30-1
Configuration File Example 30-2
Configuring the SM for the MPLS/VPN BGP LEG 30-2
CHAPTER 31 Using the MPLS/VPN BGP LEG CLU 31-1
Information About the MPLS/VPN BGP LEG CLU 31-1

BGP LEG Status 31-2
BGP LEG Detailed Status 31-2
PART 7 SOAP LEG
CHAPTER 32 About the SOAP LEG 32-1
Information About the SOAP LEG 32-1

SOAP Integration Overview 32-1
Query Interface 32-2
Secure Requests 32-2
Implementing Query Interface at the Server 32-2

viii OL-15752-01
Contents
Common Topologies 32-3
CHAPTER 33 Installing the SOAP LEG 33-1
Installing the SOAP LEG Software 33-1
Uninstalling the SOAP LEG 33-2
Upgrading the SOAP LEG 33-2
CHAPTER 34 Configuring the SOAP LEG 34-1
Information About Configuring the SOAP LEG Settings 34-1

Configuring the SOAP LEG Settings 34-1
Configuration File Example 34-2
Information about Configuring the Package Association 34-2
Configuring the Package Assocation 34-2
Package Association Example 34-4
CHAPTER 35 Using the SOAP LEG CLU 35-1
Information About the p3soap Utility 35-1

Viewing the SOAP LEG Status 35-2
Viewing the SOAP LEG Statistics 35-3
Viewing the SOAP LEG Version 35-3
Setting the username and password for Secure Requests 35-3
Resetting the username and password for Secure Requests 35-3
CHAPTER 36 Cisco WSDL 36-1
Cisco WSDL 36-1

OL-15752-01 ix
Contents

x OL-15752-01
Preface
This document explains how to install and configure the Cisco Service Control Management Suite
(SCMS) Subscriber Manager (SM) Login Event Generators (LEGs).
This document is intended for system administrators and integrators who are responsible for the
installation, configuration, and maintenance of the LEG components. The administrator or system
integrator should be familiar with the following:
• CNR extensions concept
• DHCP protocol
• MPLS/VPN architecture
• RADIUS extensions concept
• RADIUS protocol
• SOAP concepts
• Cisco Service Control Subscriber Management and Subscriber Integration concepts
For complete information about Cisco's SCMS subscriber integration concept, see the Cisco SCMS
Subscriber Manager User Guide.
Document Revision History

The Document Revision History below records changes to this document.
Cisco Service Control

Revision Release and Date Change Summary
OL-15752-01 3.1.6 • First version of this document to consolidate all LEG documentation into
May, 2008 a single guide.
• RADIUS Listener LEG changes:
– Updated the regular expression utility behavior. See Regular
Expression Examples, page 19-4 and Regular Expression Processing
versus RADIUS Listener Login Rate, page 19-5.
– Addition of performance option to p3radius command-line utility. See
Information About the p3radius Utility, page 21-1.

OL-15752-01 xi
Preface
Organization
This guide contains the following sections:
Section Title Description

1 Terms and Concepts, page 1-1 Describes the terms and concepts used in this SM
LEGs guide.
2 About the CNR LEG, page 2-1 Describes the Subscriber Manager CNR LEG
software module.
3 Installing the CNR LEG, page 3-1 Describes the CNR LEG installation procedures
for both Widows and Solaris platforms. It also
describes the uninstall procedure.
4 Configuring the CNR LEG and the Describes the configuration for the CNR LEG and
SM, page 4-1 the Subscriber Manager using the CNR LEG.
5 CNR Log Messages, page 5-1 Describes the log messages written to the CNR
Log.
6 CNR LEG Functional Specification, Describes the CNR LEG design, logging, tracing,
page 6-1 and operations performed by the CNR LEG.
7 About the DHCP Lease Query LEG, Describes the Subscriber Manager DHCP Lease
page 7-1 Query LEG software module and the terms and
concepts used in this guide. It also provides a
description of the DHCP Lease Query LEG
process and transactions.
8 Subscriber Manager Integration, Describes the procedures for installing,
page 8-1 uninstalling, and upgrading the software on the
Subscriber Manager.
9 Subscriber Manager Integration - Describes the procedures for configuring and
Configuration, page 9-1 using the software on the Subscriber Manager. It
also describes the command-line utility.
10 SCE Integration, page 10-1 Describes the procedures for installing,
uninstalling, and upgrading the software on an
SCE device.
11 SCE Integration - Configuration, Describes the procedures for configuring and
page 11-1 using the software on an SCE device. It also
describes the CLI.
12 DHCP Forwarder Application, Describes the DHCP Forwarder application,
page 12-1 installation instructions, and adding and removing
a resource.
13 About the SCE-Sniffer DHCP LEG, Describes the Subscriber Manager SCE-Sniffer
page 13-1 DHCP LEG software module and the terms and
concepts used in this guide.
It also provides a description of the SCE-Sniffer
DHCP LEG operationand transactions.

xii OL-15752-01
Preface

14 Installing the SCE-Sniffer DHCP Describes the procedures for installing the
LEG, page 14-1 software on the Subscriber Manager. It also
describes uninstalling the software and upgrading
procedures.
15 Configuring the SCE-Sniffer DHCP Describes the configuration procedure for the
LEG, page 15-1 SCE-Sniffer DHCP LEG on the SM and
configuring the Package Association.
16 Using the SCE-Sniffer DHCP LEG Provides a description of the command-line utility
CLU, page 16-1 commands when the software is installed on the
Subscriber Manager.
17 About the RADIUS Listener LEG, Describes the Subscriber Manager RADIUS
page 17-1 Listener LEG software module and the terms and
concepts used in this guide.
18 Installing the RADIUS Listener LEG, Describes the procedures for installing the
page 18-1 software on the Subscriber Manager. It also
describes uninstalling the software and upgrading
procedures.
19 Configuring the RADIUS Listener Describes the configuration procedure for the
LEG, page 19-1 RADIUS Listener LEG.
20 Configuring the RADIUS Client, Describes the configuration procedure for the
page 20-1 RADIUS Client.
21 Using the RADIUS Listener LEG Provides a description of the command-line utility
CLU, page 21-1 commands when the software is installed on the
Subscriber Manager.
22 Domain Association Algorithm, Describes the algorithm used for deciding the
page 22-1 subscriber domain to which a subscriber should
be logged on.
23 About the SCE-Sniffer RADIUS Describes the SCE-Sniffer RADIUS LEG
LEG, page 23-1 software module, and terms and concepts.
24 SCE-Sniffer RADIUS LEG Provides a description of SCE-Sniffer RADIUS
Functionality, page 24-1 LEG transactions for login and logout operations.
25 Installing the SCE-Sniffer RADIUS Describes the installation process for installing
LEG, page 25-1 the SM SCE-Sniffer RADIUS LEG.
26 Configuring the SCE-Sniffer Provides the configuration instructions to
RADIUS LEG, page 26-1 configure the SCE-Sniffer RADIUS LEG.
27 Using the SCE-Sniffer RADIUS LEG Describes the Command-Line Utilities to retrieve
CLU, page 27-1 information and statistics about the LEG.
28 About the MPLS/VPN BGP LEG, Describes the MPLS/VPN BGP LEG software
page 28-1 module, and terms and concepts.
29 Installing the MPLS/VPN BGP LEG, Describes the installation process for installing
page 29-1 the SM MPLS/VPN BGP LEG.
30 Configuring the MPLS/VPN BGP Provides the configuration instructions to
LEG, page 30-1 configure the MPLS/VPN BGP LEG.

OL-15752-01 xiii
Preface

31 Using the MPLS/VPN BGP LEG Describes the Command-Line Utility to control
CLU, page 31-1 the operation of the MPLS/VPN BGP LEG and to
retrieve information and statistics about the LEG.
32 About the SOAP LEG, page 32-1 Describes the SOAP LEG software module, and
terms and concepts.
33 Installing the SOAP LEG, page 33-1 Describes the installation process for installing
the SOAP LEG.
34 Configuring the SOAP LEG, Provides the configuration instructions to
page 34-1 configure the SOAP LEG.
35 Using the SOAP LEG CLU, Provides a description of the command-line utility
page 35-1 commands when the software is installed on the
Subscriber Manager.
36 Cisco WSDL, page 36-1 The Cisco WSDL.
Related Publications
Use this Cisco SCMS SM LEGs User Guide in conjunction with the following Cisco documentation:
• Cisco SCMS Subscriber Manager User Guide
• Cisco Service Control Application for Broadband User Guide
Conventions
This document uses the following conventions:
Convention Indication
bold font Commands and keywords and user-entered text appear in bold font.
italic font Document titles, new or emphasized terms, and arguments for which you supply
values are in italic font.
[ ] Elements in square brackets are optional.
{x | y | z } Required alternative keywords are grouped in braces and separated by
vertical bars.
[x|y|z] Optional alternative keywords are grouped in brackets and separated by
vertical bars.
string A nonquoted set of characters. Do not use quotation marks around the string or
the string will include the quotation marks.
courier font Terminal sessions and information the system displays appear in courier font.
< > Nonprinting characters such as passwords are in angle brackets.
[ ] Default responses to system prompts are in square brackets.
!, # An exclamation point (!) or a pound sign (#) at the beginning of a line of code
indicates a comment line.

xiv OL-15752-01
Preface
Note Means reader take note.
Tip Means the following information will help you solve a problem.
Caution Means reader be careful. In this situation, you might perform an action that could result in equipment
damage or loss of data.
Timesaver Means the described action saves time. You can save time by performing the action described in
the paragraph.
Warning Means reader be warned. In this situation, you might perform an action that could result in
bodily injury.
Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional
information, see the monthly What’s New in Cisco Product Documentation, which also lists all new and
revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What’s New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed
and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free
service and Cisco currently supports RSS version 2.0.

OL-15752-01 xv
Preface

xvi OL-15752-01
CH A P T E R 1
Terms and Concepts
This module defines terms and concepts that are necessary for understanding the Login Event Generators
(LEGs) and the Subscriber Manager (SM) configuration and operation. More information about all items
can be found in the Cisco SCMS Subscriber Manager User Guide.
• General Concepts, page 1-1
• CNR Concepts, page 1-3
• DHCP Concepts, page 1-4
• RADIUS Concepts, page 1-5
• MPLS/VPN BGP Concepts, page 1-7
• SOAP Concepts, page 1-9
General Concepts
• Cable/Satellite Modem, page 1-1
• CPE (Customer Premise Equipment), page 1-1
• LEG (Login Event Generator), page 1-2
• Pull-request, page 1-2
• RDR (Raw Data Record), page 1-2
• Subscriber Domain, page 1-2
• Subscriber ID, page 1-2
• Subscriber Mappings, page 1-2
Cable/Satellite Modem
A data modem that provides Internet access over cable and satellite networks. The modem usually
corresponds to a single subscriber of the Internet Service Provider (ISP).
CPE (Customer Premise Equipment)

Any equipment that an end-user can connect to the network through a modem. The end-user usually
owns multiple CPE devices that are used to connect to the Internet through a single modem.

OL-15752-01 1-1
Chapter 1 Terms and Concepts
General Concepts
LEG (Login Event Generator)

A software component that performs subscriber login and logout operations on the SM/SCE. The LEG
handles dynamic subscriber integration.
Pull-request
A message sent from a service control engine (SCE) platform to the SM or the LEG when it identifies
the use of a new subscriber IP address in the network. The SM uses the IP address provided in this
message to query the database to retrieve the subscriber data of the subscriber associated with this
address and to send its data to the SCE.
RDR (Raw Data Record)

A client/server data protocol that enables the SCE devices to export reports about network transactions
to external collectors. This is a Cisco proprietary protocol.
Subscriber Domain
The SM provides the option of partitioning SCE platforms and subscribers into subscriber domains. A
subscriber domain is a group of SCE platforms that share a group of subscribers. Subscriber domains
can be configured using the SM configuration file and can be viewed using the SM Command-Line
Utility (CLU).
It is also possible to configure domain aliases. A domain alias is a synonym for the actual domain name
in the SM. Domain aliases are configured in the SM configuration file.
For additional information about domains and domain aliases, see the Configuration File Options
module of the Cisco SCMS Subscriber Manager User Guide.
Subscriber ID
The Service Control solution requires a unique identifier for each subscriber. A subscriber ID represents
a logical subscriber entity from the service provider perspective.
Subscriber Mappings
The SCE platform requires mappings between the network IDs (IP addresses) of the flows it encounters
and the subscriber IDs. The SM database contains the network IDs that map to the subscriber IDs. The
SCE network-ID-to-subscriber mappings are constantly updated from the SM database.
The main function of the SM LEGs is to provide the SM/SCE with network-ID-to-subscriber mappings
in real time.
For information about the SCE platforms, see the Cisco SCE 1000 2xGBE Installation and
Configuration Guide and the Cisco SCE 2000 4xGBE Installation and Configuration Guide.

1-2 OL-15752-01
CNR Concepts
CNR Concepts
• Communication Link Failure Handling, page 1-3
• DHCP DoS Attack Filter, page 1-3
• Remote Procedure Call Protocol (PRPC), page 1-3
• SM C++ API, page 1-3
• SM Cable Support Module, page 1-4
• Subscriber Autologout, page 1-4
• Subscriber Mode, page 1-4
Communication Link Failure Handling

A keep-alive mechanism periodically checks the communication link (socket) between the CNR LEG
and the SM. The communication link fails when the socket is closed or a keep-alive timeout occurs. You
can configure the keep-alive timeout in the SM configuration file.
In cases where a LEG to SM link fails, you can configure the SM to clear the mappings of all the
subscribers that are updated by the failed LEG.
To learn more about communication link failure handling, see the Configuration File Options module of
the Cisco SCMS Subscriber Manager User Guide.
DHCP DoS Attack Filter

The connection between the CNR LEG and the SM is a resource that should be protected against DHCP
Denial of Service attacks. Such attacks are dispatched by sending a high rate of DHCP requests from a
certain subscriber, which can cause the connection to overflow because of too many logon messages in
a short period of time. The CNR LEG enables the administrator to use the filter that identifies such
events of multiple identical DHCP requests and filters them to reduce the rate of logon messages to a
predefined rate. The filter does not protect the CNR against attacks, but rather protects the connection
to the SM.
Remote Procedure Call Protocol (PRPC)

The CNR LEG communicates with the SM using a proprietary remote procedure call (PRPC) protocol
developed by Cisco. The SM Java, C, and C++ APIs also use PRPC. The CNR LEG uses the C++ API
as its communication layer.
SM C++ API
The SM C++ API exposes a set of operations designed to enable subscriber integration with the Cisco
system. The CNR LEG uses the SM C++ API as its basic communication layer.
For additional information about the C++ API, see the Cisco SCMS SM C/C++ API Programmer Guide.

OL-15752-01 1-3
DHCP Concepts
SM Cable Support Module

The cable support module is an SM component that executes an API friendly to cable environment
integrations. The cable support module translates between the cable subscriber terminology (CPE, CM,
and CMTS) and the generic subscriber terms used by the Cisco Service Control Management system.
The CNR LEG uses PRPC to invoke the cableLogin and cableLogout operations that are performed by
the cable support module API.
The SM cable support module is used only in the CPE as Subscriber mode.
For additional information about the cable support module, see the CPE as Subscriber in Cable
Environment module of the Cisco SCMS Subscriber Manager User Guide.
Subscriber Autologout
The SM supports the configuration of an autologout timer (lease-time) for each subscriber. The timer is
set when performing a subscriber cableLogin or login operation. The CNR LEG extracts and sets an
autologout value from the DHCP IP lease expiration time option.
Subscriber Mode
The Subscriber Mode defines which entity is referred to as the subscriber in the LEG and in the SM.
Cable providers usually prefer using the Cable Modem (CM) as the subscriber entity to be assigned
multiple IP addresses (one per Customer Premises Equipment (CPE)).
The CNR LEG supports the CPE as Subscriber and CM as Subscriber (the default) modes, as defined
by the configuration.
The CNR LEG works with the SM cable support module when operating in the “CPE as Subscriber”
mode. For additional information about cable environment subscriber modes, see the the CPE as
Subscriber in Cable Environment module of the Cisco SCMS Subscriber Manager User Guide.
DHCP Concepts
• DHCP ACK Packet, page 1-4
• DHCP Lease Extension Transaction (Renewal), page 1-5
• DHCP Lease Query Transaction, page 1-5
• DHCP Release Transaction, page 1-5
• DHCP Sniffer, page 1-5
• Subscriber Policy, page 1-5
DHCP ACK Packet

The final packet that is transmitted from the DHCP server in each DHCP transaction (except the release
transaction). After the transmission of the DHCP ACK packet, the results of the transaction are final.

1-4 OL-15752-01
RADIUS Concepts
DHCP Lease Extension Transaction (Renewal)

A DHCP transaction for renewal of the entity lease time. When the lease time has been reached, the
network entity is removed from the network. The LEG uses this query to logon the subscriber using the
new lease time.
DHCP Lease Query Transaction

The DHCP Lease Query transaction is a DHCP transaction with special message types that enable,
among other things, clients to query DHCP servers regarding the owner and the lease-expiration-time of
an IP address.
An IETF standard defines the DHCP Lease-Query transaction. For more information, see the IETF
website.
DHCP Release Transaction

A DHCP transaction for releasing IP addresses. This transaction is used to logout network entities from
the network. The DHCP release transaction is rarely used. Logout is usually performed when the lease
time expires, and not directly with a release transaction. The LEG uses the release query to logout a
subscriber from the SM.
DHCP Sniffer
The software logic inside the SCE device that analyzes DHCP traffic and sends the information to the
SCE-Sniffer DHCP LEG using the raw data record (RDR) protocol.
Subscriber Policy
A subscriber policy package usually defines the policy enforced by Cisco SCMS solutions on each
subscriber. The DHCP Lease Query LEG and the SCE-Sniffer DHCP LEG can handle the package ID
in any of the following ways:
• Set the policy according to configurable options of the DHCP initial login or lease extension
transactions
• Set the policy using a constant default value
• Leave the policy unset
For additional information, see the Cisco Service Control Application for Broadband User Guide.
RADIUS Concepts
• NAS (Network Access System), page 1-6
• RADIUS Accounting Transactions, page 1-6
• RADIUS Accounting Start/Interim/Stop, page 1-6
• RADIUS Authentication Transactions, page 1-6

OL-15752-01 1-5
RADIUS Concepts
• RADIUS Sniffer, page 1-6

• Subscriber Mappings over VPN, page 1-6
• Subscriber Policy, page 1-7
NAS (Network Access System)

A network device that serves as an access point for a remote user. It initiates RADIUS transactions to
the RADIUS server to authenticate a remote user.
The RADIUS Listener LEG refers to all of its RADIUS clients as NAS devices, even though they might
be RADIUS servers acting as a proxy or forwarding messages.
RADIUS Accounting Transactions

The RADIUS accounting transactions are used to keep track of the services used by the user for
administrative purposes. The LEG supports RADIUS accounting based on RFC 2866. The only
RADIUS accounting packet the LEG uses is ACCOUNTING-REQUEST.
RADIUS Accounting Start/Interim/Stop

The RADIUS Accounting messages must hold an attribute called Acct-Status-Type. This attribute can
receive the value of start, interim-update, stop, or other RADIUS Accounting messages. An
Accounting-Start message contains the Acct-Status-Type with the value start.
For additional information, see the relevant RADIUS RFC documentation.
RADIUS Authentication Transactions

The RADIUS transactions are used for authenticating a remote user, and authorizing access to the
network's resources. The LEG supports RADIUS authentication based on RFC 2865. The authentication
RADIUS packets used by the LEG are ACCESS-REQUEST and ACCESS-ACCEPT.
RADIUS Sniffer
The software logic inside the SCE device that analyzes RADIUS traffic and sends the information to the
SCE-Sniffer RADIUS LEG using the RDR protocol.
Subscriber Mappings over VPN

Starting from version 3.1.5 the RADIUS Listener LEG supports dynamic integration for subscriber
mappings over VPN. The LEG can be configured to extract a VLAN-ID from a RADIUS attribute and
use it along with the extracted IP address.
Note Currently the LEG supports subscriber mappings over VPN only for VPNs that are defined by a
VLAN-ID (also referred to as "VPNs of type VLAN").

1-6 OL-15752-01
MPLS/VPN BGP Concepts
Note The SM is able to learn VLAN VPNs automatically: upon subscriber login with a VLAN-ID that is
unknown to the SM, the SM will add the VPN automatically using the VLAN-ID as a VPN name
Subscriber Policy
A subscriber policy package usually defines the policy enforced by Cisco SCMS solutions on each
subscriber. The RADIUS Listener LEG and the SCE-Sniffer RADIUS LEG can handle the package ID
in any of the following ways:
• Set the policy according to configurable attributes of the RADIUS transactions
• Set the policy using a constant default value
• Leave the policy unset
For additional information, see the Cisco Service Control Application for Broadband User Guide.

• BGP (Border Gateway Protocol), page 1-7
• CE (Customer Edge), page 1-7
• MPLS (Multi Protocol Label Switching), page 1-8
• PE (Provider Edge), page 1-8
• RD (Route Distinguisher), page 1-8
• RR (Route Reflector), page 1-8
• RT (Route Target), page 1-8
• VPN ID, page 1-8
• VPN (Virtual Private Networking), page 1-8
• VRF (Virtual Routing and Forwarding), page 1-9
BGP (Border Gateway Protocol)

An exterior gateway protocol used on the Internet to provide loop-free routing between different
autonomous systems.
In the context of MPLS/VPN, the BGP protocol is used to distribute the MPLS/VPN routes of a PE router
to its neighboring PE routers.
CE (Customer Edge)
A router on the service provider site that connects to the PE (Provider Edge) router in the MPLS core.
The CE router only passes the message packet with the IP address and is not concerned with the
MPLS/VPN label.

OL-15752-01 1-7
MPLS (Multi Protocol Label Switching)

A switching method that forwards IP traffic using a label. This label instructs the routers and the
switches in the network where to forward the packets based on pre-established IP routing information.
PE (Provider Edge)
A router in the service provider MPLS core that provides routing information between the customer
router and the MPLS/VPN network. The PE router maintains a VRF (Virtual Routing and Forwarding)
table for each customer site to determine how to route the packet.
RD (Route Distinguisher)
An 8-byte value that is concatenated with an IPv4 prefix to create a unique VPN IPv4 prefix.
The RD uniquely identifies the VPN VRF within a PE router.
RR (Route Reflector)
A network element in the service provider network that is used to distribute BGP routes to the service
provider BGP-enabled routers. Route Reflectors provide a mechanism for both minimizing the number
of update messages transmitted within the autonomous system and reducing the amount of data that is
propagated in each message.
RT (Route Target)
Used by the routing protocols to control import and export policies and to build arbitrary VPN topologies
for customers.
VPN ID
The Service Control solution requires a unique identifier for each VPN. A VPN ID represents a logical
VPN entity from the service provider perspective.
VPN (Virtual Private Networking)

A technology for securely connecting a computer or network to a remote network over an intermediate
network such as the Internet.
VPNs can use an insecure public network such as the Internet to connect two networks. They can also
use an insecure public network to connect a network and a remote computer, or employ technologies
such as tunneling, encryption, and authentication to secure the connection.

1-8 OL-15752-01
SOAP Concepts
VRF (Virtual Routing and Forwarding)

In general, a VRF includes the routing information that defines the VPN site that is attached to a PE
router. A VRF consists of an IP routing table, a forwarding table, a set of interfaces that use the
forwarding table, and a set of rules and routing protocols that determine what goes into the forwarding
table.
SOAP Concepts
• SOAP, page 1-9
• UsernameToken Profile, page 1-9
• WSDL, page 1-9
• WSS, page 1-9
SOAP
SOAP is a lightweight protocol intended for exchanging structured information in a decentralized,
distributed environment. It uses XML technologies to define an extensible messaging framework
providing a message construct that can be exchanged over a variety of underlying protocols. The
framework has been designed to be independent of any particular programming model and other
implementation specific semantics.
UsernameToken Profile
The <wsse:UsernameToken> is an element introduced in the WSS SOAP Message Security documents
as a way of providing a username.
WSDL
WSDL is an XML format for describing network services as a set of endpoints operating on messages
containing either document-oriented or procedure-oriented information. The operations and messages
are described abstractly, and then bound to a concrete network protocol and message format to define
an endpoint. Related concrete endpoints are combined into abstract endpoints (services).
WSS
WS-Security (Web Services Security) is a communications protocol providing a means for applying
security to Web Services. Originally developed by IBM, Microsoft, and VeriSign, the protocol is now
officially called WSS and is developed and maintained via committee in Oasis-Open.
The protocol contains specifications on how integrity and confidentiality can be enforced on Web
Services messaging. WS-Security incorporates security features in the header of a SOAP message and
thus works in the application layer. Thus, it ensures end-to-end security.

OL-15752-01 1-9
SOAP Concepts

1-10 OL-15752-01
P A R T 1
CNR LEG
CH A P T E R 2
About the CNR LEG
This module describes the Subscriber Manager CNR LEG software module.
The Cisco Network Registrar (CNR) Login Event Generator (LEG) is a software module that forwards
login and logout events from the CNR to the Cisco Service Control Management Suite Subscriber
Manager (SCMS SM). The CNR LEG is actually a CNR extension developed in C++. The extension
points used by CNR LEG are:
• init-entry
• post-send-packet
• post-packet-decode
The CNR LEG Module

The CNR LEG module requires the use of option 82 sub-option 2 (Relay-Agent-Information Option with
the Remote-Id sub-option), which contains the CM-MAC, in all DHCP requests. If option 82 does not
exist in a renewal transaction, an attempt to extend the lease based solely on the IP address is performed.
This will succeed only if the IP address was previously logged in to the Subscriber Manager (SM) by the
LEG, in the event of a full DHCP transaction, or via other interfaces to the SM.
The CNR LEG protects the SM and the connection to the SM from any DHCP Denial of Service (DoS)
attacks, which are performed on the CNR. To reduce the login rate to the SM, the LEG ignores identical
DHCP requests that are approved by the CNR. The requests are sent to the CNR in short time intervals.
For additional information about extending the CNR functionality using extension points, see the CNR
CLI Reference Guide.
The CNR LEG was carefully developed and thoroughly tested on Solaris and Windows platforms for
both functional correctness and robustness. It does not jeopardize the stability or the reliability of the
CNR.

OL-15752-01 2-1
Chapter 2 About the CNR LEG
The CNR LEG Module

2-2 OL-15752-01
CH A P T E R 3
Installing the CNR LEG
This module describes the CNR LEG installation procedures for both Widows and Solaris platforms. It
also describes the uninstall procedure.
• Prerequisites, page 3-1
• Package Contents, page 3-1
• Installing the CNR LEG on Windows, page 3-2
• Installing the CNR LEG on Solaris, page 3-3
• Uninstalling the CNR LEG, page 3-4
Prerequisites
CNR LEG is operable with any CNR version 5.0 or later.
The platform requirements (OS/CPU/RAM/disk) are the same as the CNR requirements for both
Windows and Solaris. See the Cisco Network Registrar (CNR) Installation Guide for platform
requirements details.
Package Contents
The CNR LEG distribution part of the SCMS-SM LEG distribution file and is located in the CNR_LEG
directory. The following table describes the contents of the CNR LEG distribution package supplied by
Cisco.
Table 3-1 File layout of CNR LEG distribution package
Root Folder (under root) File name Notes

pkg-ext-dir
readme.cnrleg Short description of CD
content
INSTALL.dat Quick installation
instructions
doc

OL-15752-01 3-1
Chapter 3 Installing the CNR LEG
Installing the CNR LEG on Windows
Table 3-1 File layout of CNR LEG distribution package (continued)

cnrleg.cfg Sample configuration
file
solaris
libcnrleg.so Solaris distribution in a
single library file
winnt
asn1ber.dll
asn1rt.dll
cnrleg.dll
Installing the CNR LEG on Windows

Note The directory in which the CNR is installed is referred to as cnr-inst-dir.
Step 1 Extract the SM LEG distribution file

Step 2 Locate the CNR LEG distribution tar file under the CNR LEG directory
Step 3 Extract the CNR LEG distribution and copy the files
• Unzip the CNR Package to pkg-ext-dir.
• Copy all files under pkg-ext-dir\winnt to <cnr-inst-dir>\Extensions\DHCP\Dex\.
If the \Extensions\DHCP\Dex\ folder does not exist, it must be created.
• Copy the sample configuration file from pkg-ext-dir\doc to a directory of your choice, hereafter
referred to as cfg-dir.
Step 4 Configure the CNR LEG using the sample configuration file
See Information About Configuring the CNR LEG, page 4-1.
Step 5 Configure the SM
See Information About Configuring the Subscriber Manager, page 4-4.
Step 6 Register the CNR LEG with the CNR
• Run the CNR <cnr-inst-dir>/bin/nrcmd command-line utility.
• Log in to the CNR nrcmd CLU.
To log in, type the following command:
nrcmd [-C cluster] [-N user] [-P password]
• Configure the following:
nrcmd>extension smleg create dex cnrleg.dll cnrLegPostSendPacket
nrcmd>extension smleg set init-entry=cnrLegInitEntry
nrcmd>extension smleg set init-args=cfg-dir/cnrleg.cfg
nrcmd>dhcp attachExtension post-send-packet smleg 11
nrcmd>extension smlegext create dex cnrleg.dll cnrLegPostPacketDecode
1. Any sequence number can be used for this command.

3-2 OL-15752-01
Installing the CNR LEG on Solaris
nrcmd>dhcp attachExtension post-packet-decode smlegext 11

nrcmd>save
nrcmd>server DHCP reload
Note You must use the cfg-dir full path in the init-args argument.
Note You must use a slash (“/”) and not a back-slash (“\”) as the path separator.
Installing the CNR LEG on Solaris

Step 1 Extract the SM LEG distribution file
Step 2 Locate the CNR LEG distribution tar file under the CNR LEG directory
Step 3 Extract the CNR LEG distribution and copy the files
• Extract the CNR Package to pkg-ext-dir. For example:
#>tar xvf cnr-leg-dist.tar
• Copy libcnrleg.so under pkg-ext-dir/solaris to <cnr-inst-dir>/extensions/dhcp/dex.
• Copy the sample configuration file from pkg-ext-dir/doc to a directory of your choice, hereafter
referred to as cfg-dir.
Step 4 Configure the CNR LEG using the sample configuration file
See Information About Configuring the CNR LEG, page 4-1
Step 5 Configure the SM
See Information About Configuring the Subscriber Manager, page 4-4.
Step 6 Register the CNR LEG with CNR
nrcmd>extension smleg create dex libcnrleg.so cnrLegPostSendPacket
nrcmd>extension smleg set init-entry=cnrLegInitEntry
nrcmd>extension smleg set init-args=cfg-dir/cnrleg.cfg
nrcmd>dhcp attachExtension post-send-packet smleg 12
nrcmd>extension smlegext create dex libcnrleg.so cnrLegPostPacketDecode
nrcmd>dhcp attachExtension post-packet-decode smlegext 13
nrcmd>save
Note You must use the cfg-dir full path in the init-args argument.

OL-15752-01 3-3
Uninstalling the CNR LEG
Note You must use a slash (“/”) and not a back-slash (“\”) as the path separator.
Uninstalling the CNR LEG

This section explains how to uninstall the CNR LEG. The uninstall procedure is applicable for both
Windows and Solaris platforms.
Step 1 Un-register CNR LEG from CNR

nrcmd>dhcp detachExtension post-send-packet 1
nrcmd>extension smleg delete
nrcmd>dhcp detachExtension post-packet-decode 1
nrcmd>extension smlegext delete
nrcmd>save
Step 2 Delete the LEG distribution files
• Delete all files copied to <cnr-inst-dir>/extensions/dhcp/dex
• Delete the configuration file (cfg-dir/cnrleg.cfg).

3-4 OL-15752-01
CH A P T E R 4
Configuring the CNR LEG and the SM
This module explains how to configure the CNR LEG and to configure the Subscriber Manager (SM) to
use the CNR LEG module.
• Information About Configuring the CNR LEG, page 4-1
• Information About Configuring the Subscriber Manager, page 4-4
Information About Configuring the CNR LEG

The CNR configuration file offers the following configuration options to the user:
• SM IP address—The IP address of the SM
• SM port—The TCP port on which the SM PRPC server listens
• Subscriber mode—The subscriber entity to be used by the LEG: CM as subscriber (default) or CPE
as subscriber
• Lease time option—The DHCP option number from which to extract the lease expiration time that
is to be sent to the SM
• Attack filter parameters—Defines whether the DHCP DoS attack protection is on and defines how
to perform the filtering
Information About Setting the SM IP Address and Port

• Setting the SM IP Address and Port, page 4-1
• SM IP Address and Port Example, page 4-2
Setting the SM IP Address and Port

You must set the SM IP address correctly in order for the LEG to operate.
The default PRPC TCP port number generally does not need to be changed. The SM port default is TCP
14374.
The SM PRPC port can be retrieved from the SM configuration file. For additional information, see the
Configuration File Options module of the Cisco SCMS Subscriber Manager User Guide.

OL-15752-01 4-1
Chapter 4 Configuring the CNR LEG and the SM
SM IP Address and Port Example

The following example is a portion of a sample CNR configuration file showing how to configure the
SM IP address and port:
[sm]
# SM IP address
ip_address= 216.239.37.99
# SM PRPC Server port. default 14374
#port=14374
Information About Setting the Subscriber Mode

• Setting the Subscriber Mode, page 4-2
• Subscriber Mode Example, page 4-2
Setting the Subscriber Mode

The LEG can operate in one of two modes:
• CM as Subscriber—Each CPE login/logout/lease extension triggers a logon operation to the SM
using the corresponding CM MAC as the subscriber ID.
• CPE as Subscriber—Each CPE is a separate subscriber entity. Each CPE login/logout/lease
extension triggers a logon operation to the SM using both the CPE MAC and the CM MAC as the
subscriber ID.
Subscriber Mode Example

Subscriber Mode:
• CM as Subscriber:
[general]
# defines who is the subscriber to refer to the CM or the CPE.
# default: cm_as_subscriber optional values: cm_as_subscriber \
# cpe_as_subscriber
subscriber_mode=cm_as_subscriber
• CPE as Subscriber:
[general]
# defines who is the subscriber to refer to the CM or the CPE.
# default: cm_as_subscriber optional values: cm_as_subscriber \
# cpe_as_subscriber
subscriber_mode=cpe_as_subscriber
Information About Setting the Attack Filter Parameters

• Setting the Attack Filter Parameters, page 4-3
• Attack Filter Example, page 4-3

4-2 OL-15752-01
Setting the Attack Filter Parameters

To enable the DHCP Denial of Service (DoS) attack protection, the enabled option must be set. The
attack filter has two parameters that define its operation:
• The timeout parameter defines the minimal interval in seconds between identical DHCP requests
(login/renew transactions). If two identical requests reach the CNR within the time interval specified
in this parameter, the LEG ignores the second request. The CNR does not trigger the second login
to the SM.
• The num_of_entries parameter defines the number of DHCP transaction information entries that
the attack filter can hold at any given time. This parameter affects the amount of memory allocated
by the LEG for the DoS attack protection filter. Change this parameter only if the LEG supports a
high transaction rate.
Attack Filter Example

attack filter parameters:
[attack filter]
# enable or disable the attack filtering mechanism in the LEG
# can be set to true or false. default true.
enabled=true
# minimum time in seconds between DHCP login/renew transactions of
# the same subscriber with the same IP. default = 10 seconds
timeout=10
# the number of attack transactions detected on this user that
# should generate a log message. setting 0 disables this logging.
# note: the first attack detection is always logged (unless
# logging is disabled)
# default: log every 100 attack transactions.
log_interval=100
Information About Setting the Lease Time Option

• Setting the Lease Time Option, page 4-3
• Lease Time Option Example, page 4-4
Setting the Lease Time Option

To enable subscriber auto-logout at lease time expiration on the SM, the lease_time option must be set.
The CNR LEG can extract the IP address lease expiration from one of the following DHCP option
numbers:
• 51 (default)
• 58
• 59
For additional information about the auto-logout mechanism, see Information About Configuring
Autologout, page 4-6.

OL-15752-01 4-3
Information About Configuring the Subscriber Manager
Lease Time Option Example

lease time option:
lease_time_option=51

Use the SM configuration file to configure the Subscriber Manager. For additional information, see the
Configuration File Options module of the Cisco SCMS Subscriber Manager User Guide.
• Information About Configuring SM-LEG Failure Handling, page 4-4
• Information About Setting Domain Aliases, page 4-5
• Information About Configuring Autologout, page 4-6
• Configuring the PRPC Server, page 4-7
Information About Configuring SM-LEG Failure Handling
Note It is important to properly configure SM-LEG failure handling on the SM before continuing with the
CNR LEG configuration. For information about configuring the SM, See the Configuration File Options
module of the Cisco SCMS Subscriber Manager User Guide.
In order to configure the failure handling, you must do the following in the configuration file:
• Activate SM-LEG Failure Handling
• Set LEG-Domains associations
Information About Activating SM-LEG Failure Handling

• Activating SM-LEG Failure Handling, page 4-4
• SM-LEG Failure Handling Example, page 4-4
Activating SM-LEG Failure Handling

By default, SM-LEG failure handling is not activated. In order to activate it you must set the
clear_all_mappings parameter to true. If required, you can also change the timeout value.
SM-LEG Failure Handling Example

The following example is a portion of a sample p3sm.cfg configuration file showing how to configure
SM-LEG failure handling:
[SM-LEG Failure Handling]
# The following parameter defines the behavior of the SM in case of
# LEG-SM connection failure.
# This parameter is relevant only for cases SM and LEG are running
# on different machines.
# Note that this parameter defines a behavior that is similar for
# ALL connected LEGs. If the parameter is set to true then in case
# of LEG-SM connection failure that is not recovered within the

4-4 OL-15752-01
# defined timeout, the mappings of all subscribers in the domains

# defined in the 'LEG-Domains Association' section for the LEG
# that was disconnected, will be removed.
#
# IMPORTANT: LEG Domains must be defined in the following section
# in case this parameter is set to 'true'.
#
# Optional values: [true/false]. Default: false.
clear_all_mappings=true
# The following parameter defines the time in seconds from a LEG-SM
# connection failure until clearing the mappings in the SM database.
# Default value: 60.
timeout=60
Information About Setting LEG-Domains Associations

• Setting LEG-Domains Associations, page 4-5
• LEG-Domains Association Example, page 4-5
Setting LEG-Domains Associations

You must set LEG-Domains associations in order for the SM-LEG failure handling to work. The
CNR-LEG name to be used in this section is a concatenation of the hostname of the machine on which
the LEG is installed and the suffix “.CNR.LEG”.
An alternate way to retrieve the CNR-LEG name is by using the p3rpc utility. This utility displays all
clients currently connected to the PRPC server, including the CNR.
Use the p3rpc CLU to retrieve the CNR LEG name:
>p3rpc -show-client-names
LEG-Domains Association Example

If the hostname of the machine on which the LEG is installed is netserv5, use netserv5.CNR.LEG for
the LEG name in the configuration file. The following example assumes that the name of the subscriber
domain associated with the CNR LEG is subscribers.
The following example is a portion of a sample p3sm.cfg configuration file showing how to set
LEG-Domains associations.
[LEG-Domains Association]
# The following parameter defines domains that the mapping of all
# subscribers that belong to them will be cleared on LEG-SM
# connection failure. The key is the LEG NAME and the value is a
# comma separated list of domain names.
# A value of * in domain names stands for all the subscriber domains
# in the system.
# A value of * in LEG name means all the LEGs that are connected to
# the SM.
# LEG NAME1 = domain_name1,domain_name2
# LEG NAME2 = domain_name2,domain_name3
netserv5.CNR.LEG=subscribers
Information About Setting Domain Aliases

• Setting Domain Aliases, page 4-6
• Domain Aliases Example, page 4-6

OL-15752-01 4-5
Setting Domain Aliases

You must set domain aliases in order for the CNR LEG to operate correctly.
The CNR LEG uses the CMTS IP address for the subscriber domain name. You should make sure that
all the CMTS IP addresses appear as an alias to exactly one subscriber domain. Use the SM configuration
file to configure domain aliases.
Note You do not have to configure domain aliases in those cases where each CMTS updates a single
subscriber domain and you have configured the subscriber domain names in the SM to be the IP address
of the matching CMTS.
Domain Aliases Example

In this example, the SM is configured with the following:
• A single subscriber domain named subscribers
• Four CMTS devices with the following IP addresses:
• 209.247.228.201
• 209.247.228.202
• 69.42.72.147
• 69.42.72.148
the domain aliases.
[Domain.subscribers]
# The following parameter defines domain aliases. When subscriber
# information is received from the LEG with certain alias the
# information will be distributed to the domain that matches this
# alias - domain that contains this alias in its aliases list.
#
# A typical alias could be a network device IP address. For example,
# each string in the values can be the IP address of a NAS or a
# CMTS.
#
# In order to distribute all subscriber operations on all unmapped
# domains to a certain domain use aliases=*. Note that only one
# domain section may include this alias.
aliases=209.247.228.201,209.247.228.202,69.42.72.147,69.42.72.148
Information About Configuring Autologout

• Configuring Autologout, page 4-7
• Autologout Example, page 4-7

4-6 OL-15752-01
Configuring Autologout
To automatically log out subscribers when their lease time expires, you must configure the SM
autologout interval. After every autologout interval time, the SM checks which subscriber IP addresses
have a lease time that has expired and begins to automatically remove these IP addresses from the
system.
Lease time is the timeout defined by the LEG during the login operation of each IP address, based on
the lease-time option. All subscriber login events will start a timer of lease_time seconds. When the
timer expires and the grace_period, which is another configuration parameter, has also passed, the
subscriber's IP addresses are removed causing the subscriber to be removed from the SCE platform
database. If the subscriber logs on with an existing IP address during the countdown period, the timer is
reset and the countdown period restarts.
If the autologout value is set to zero (0), the SM's autologout mechanism is disabled.
If the autologout interval is set to a value greater than zero, the SM's autologout mechanism is enabled.
Note The subscriber record (with no mappings) remains in the SM database, preserving the subscriber state.
Autologout Example
the autologout interval to 6 minutes:
[Auto Logout]
# The following parameter configures the time between each run of
# the auto-logout mechanism. After every “auto-logout” time
# interval, the SM checks which subscriber IP addresses have a lease
# time that has expired, and begins to automatically remove these IP
# addresses from the system (causing it to be removed from the SCE
# platform's database).
# Auto-logout should be activated when the LEG/API cannot provide
# logout indications.
auto_logout_interval=360
# The following parameter defines the grace period in seconds for
# subscriber auto logout. A subscriber will be logged out only after
# timeout period + grace period seconds.
grace_period=10
# The following parameter defines the maximum rate (logouts per
# second) that the auto-logout task will perform logouts from the
# system. This enables to spread the load of the logout operations
# over time, and reduce the performance impact on other operations.
# the value should be calculated so it spreads the logouts over at
# least half of 'auto_logout_interval' time. (default 50)
max_rate=50
Configuring the PRPC Server

To enable the CNR LEG to communicate with the SM, the PRPC server must be up and running. The
RPC server is started by default, therefore it does not require special configuration.
The following example is a portion of a sample p3sm.cfg configuration file showing the PRPC server
configuration:

OL-15752-01 4-7
[RPC.Server]
# RPC server port (default 14374)
port=14374
To view the status of the PRPC server in the SM, use the p3rpc CLU.
>p3rpc --show

4-8 OL-15752-01
CH A P T E R 5
CNR Log Messages
This module describes the log messages written to the CNR Log.
Log Messages
The following messages are displayed during the LEG startup procedure. (This message is logged every
time the DHCP server is restarted):
• "CNR LEG: init entry called - starting initialization" – CNR LEG
initialization was called
• "CNR LEG: finished initialization successfully"
The following messages are displayed – containing the configuration or default parameters – at
initialization:
• "CNR LEG: thread priority =<integer value>"
• "CNR LEG: buffer size =<integer value>"
• "CNR LEG: reconnect timeout =<integer value>"
• "CNR LEG: encoding =<encoding>"
• "CNR LEG: KA duration =<integer value>"
• "CNR LEG: session timeout =<integer value>"
• "CNR LEG: debug mode on =<integer value>"
• "CNR LEG: trace level =<integer value>"
• "CNR LEG: lease time option =<integer value>"
• "CNR LEG: SM port =<integer value>"
• "CNR LEG: SM IP =<IP address>"
• "CNR LEG: report errors on =<integer value>"
• "CNR LEG: CM as Subscriber =<integer value>"
• "CNR LEG: Attack-Filter on =<integer value>"
• "CNR LEG: Attack threshold <integer value>sec"
• "CNR LEG: Filter entries =<integer value>"
• "CNR LEG: Log filter every <integer value> attacks"
• "CNR LEG: DEBUG MODE ON - enabling trace level <trace level>"

OL-15752-01 5-1
Chapter 5 CNR Log Messages
Log Messages
The following messages are displayed if there is a configuration error:

• "CNR LEG: the file <filename>was not found" – configuration file was
not found, you must fix the configuration or move the file to the
correct location.
• "CNR LEG: no SM IP address in the configuration file - aborting" –
the SM IP address is the only parameter that is required in the
configurtion file.
• "CNR LEG: invalid Attack Filter configuration parameters must be
positive"
• "CNR LEG: unable to initialize the PRPC client - aborting"
The following messages are displayed every time the DHCP server is stopped:
• "CNR LEG: init entry called - starting un-initialization"
• "CNR LEG: finished uninitialization successfully"
The following messages are displayed when triggered by the attack filter:
• "CNR LEG: Identified attack start of CM <name>, IP <IP address> -
filtering (total attacks - <number of attacks>)" – logged at detection of the
attack. 'total attacks' refers to the total number of attacks detected from all devices by this LEG.
• "CNR LEG: Identified attack number <attack number> of CM <name>, IP
<IP address> - filtering (total attacks - <number of attacks>)" –
logged every 100 sequential attack-packets of a certain device.
The following messages are displayed in response to a device login or a renewal failure:
• "CNR LEG: failed to extend lease IP <IP address> - probably buffer
overflow" – logged in CM as subscriber mode when the request does not contain option 82
• "CNR LEG: CPE Login - failed to login CM <name>, IP <IP address> -
probably buffer overflow" – logged in CM as subscriber mode when the request contains
option 82
• "CNR LEG: CM Login - failed to login CM <name>, IP <IP address> -
probably buffer overflow" – logged in CPE as subscriber mode
• "CNR LEG: CPE Login - failed to login CPE <name>, IP <IP address> -
The following messages are displayed in response to device logout failures:
• "CNR LEG: CPE Logout - failed to logout IP <IP address> - probably
buffer overflow" – logged in CM as subscriber mode when the request does not contain
option 82
• "CNR LEG: CPE Logout - failed to logout CM <name>, IP <IP address>
- probably buffer overflow" – logged in CM as subscriber mode when the request
contains option 82
• "CNR LEG: CM Logout - failed to logout CM <name>, IP <IP address> -
• "CNR LEG: CPE Logout - failed to logout CPE <name>, IP <IP address>
- probably buffer overflow" – logged in CPE as subscriber mode

5-2 OL-15752-01
CH A P T E R 6
CNR LEG Functional Specification
This module describes the CNR LEG design, logging, tracing, and operations performed by the CNR
LEG.
The purpose of this appendix is to provide insight into the CNR LEG operation and integration with
CNR.
• CNR LEG High Level Design, page 6-1
• Logging and Tracing, page 6-2
• Extensions Point Operation, page 6-2
CNR LEG High Level Design

The CNR LEG uses extension points:
• init-entry
• post-packet-decode
• post-send-packet
When an extension point hook is called, the following sequence of events takes place:
1. The extension point hook performs the minimal computation necessary to extract all the required
data and calls a Nonblocking C++ API operation.
2. The Nonblocking operation encodes a message and places it in a queue.
3. The Nonblocking C++ API network task reads messages from the message buffer and sends them
over the network to the PRPC Server on the SM.
4. The PRPC Server decodes the message and passes it to the cable support module, which sets up the
subscribers in the SM database using the SM core functionality.

OL-15752-01 6-1
Chapter 6 CNR LEG Functional Specification
Logging and Tracing
Figure 6-1 CNR LEG High Level Design
SM CNR LEG
Cable
post-send-packet
support
module post-packet-encode
SM Core init-entry
functionality Extension Point
loginCable logoutCable
PRPC
Server
Message
queue
Network
Network task
157052
Non-blocking C++ API
The only operations performed in the context of the CNR extension dispatching thread are message
creation and placement in a message queue. A separate thread performs the heavy network operations.
Note that if for some reason the message queue is full, the message will be dropped to avoid the risk of
creating a delay, which would damage CNR performance.
Logging and Tracing

By default, the CNR LEG logs its messages to the CNR log. The LEG supports a debug mode and several
trace levels. The LEG configuration file controls logging and tracing.
Note Changes made to the LEG configuration file become effective only when the LEG is restarted.
Extensions Point Operation

This section briefly describes the operations performed by the CNR LEG at each extension point.
• init-entry, page 6-3
• post-send-packet, page 6-3
• post-packet-decode, page 6-3

6-2 OL-15752-01
init-entry
The extension point init-entry initializes and terminates the CNR LEG.
During initialization, the CNR LEG performs the following operations:
• Reading the configuration file
• Initializing the LEG logging and tracing
• Creating a Nonblocking C++ API instance and connecting it to the SM
• Starting the C++ API network-task thread
During termination, the CNR LEG performs the following operations:
• Stopping and freeing the Nonblocking C++ API instance
• Stopping the C++ API network-task thread
post-send-packet
The extension point post-send-packet sends the following cableLogin operations to the SM:
• Verifying that the request-dictionary is for DHCP REQUEST and the response dictionary is for
DHCP ACK
• Extracting CM-MAC, CPE-MAC, and CMTS-IP from the request dictionary
• Extracting the assigned CPE-IP and lease time from the response dictionary
• In CM as Subscriber mode CM requests are ignored
• Calling the Nonblocking C++ API cableLogin or login operation with the parameters extracted
• If no CM-MAC (option 82) is found, an attempt to extend the lease based solely on the IP address
is performed
post-packet-decode
The extension point post-packet-decode sends the following cableLogout or logout operations to the
SM:
• Verifying that the request dictionary is for either DHCP RELEASE or DHCP DECLINE
• Extracting CM-MAC, CPE-MAC, CPE-IP, and CMTS-IP from the request dictionary
• Calling the Nonblocking C++ API cableLogout\logout operation with the parameters extracted

OL-15752-01 6-3

6-4 OL-15752-01
P A R T 2
DHCP Lease Query LEG

CH A P T E R 7
About the DHCP Lease Query LEG
This module describes the Service Control Management Suite (SCMS) Subscriber Manager (SM) DHCP
Lease Query Login Event Generator (LEG) software module.
• Information About the DHCP Lease Query LEG, page 7-1
• Information About DHCP Lease Query LEG Functionality, page 7-3
Information About the DHCP Lease Query LEG

The SCMS SM DHCP Lease Query LEG is a software module that handles pull-requests from the
different service control engine (SCE) platforms in the network. The LEG queries the DHCP server
using a DHCP Lease-Query transaction. The DHCP Lease Query LEG can be run on the SM server or
on the SCE device. If you use an SM, the LEG must be used on the SM, not on the SCE.
DHCP Lease Query LEG Operation

The following diagram represents the operation of the DHCP Lease Query LEG:

OL-15752-01 7-1
Chapter 7 About the DHCP Lease Query LEG
Information About the DHCP Lease Query LEG
Figure 7-1 DHCP Lease Query LEG Operation - SM Installation
SCE
Traffic (1)
Pull Pull
Response Request
(6) (2)
Pull (3) Lease

Login (5) Query (4)
DHCP DHCP
SM Lease Server
Query
157054
LEG
The subscriber's traffic (1) triggers a pull-request from the SCE (2). The SM receives the request for
processing. If the SM does not find a subscriber with a matching IP address in the subscriber database,
it passes the pull-request to the DHCP Lease Query LEG (3). The LEG queries the DHCP server. If the
server finds a match for the IP address in its database, the server replies with the subscriber information
(4). The LEG performs a login operation (5). This operation updates the subscriber database based on
the received information and logs the subscriber into the SCE (6), which triggered the pull-request.
If desired, install the DHCP Lease Query LEG directly on the SCE device to integrate the SCE with
DHCP servers without the use of an SM server. The following diagram represents the operation of the
LEG when installed on the SCE device:
Figure 7-2 DHCP Lease Query LEG Operation - SCE Installation
SCE
Traffic (1)
Pull Pull
Response Request
(4) (2)
Lease
Query (3)
DHCP DHCP
Lease Server
Query
157055
LEG

7-2 OL-15752-01
Information About DHCP Lease Query LEG Functionality
The subscriber's traffic (1) triggers a pull-request from the SCE (2). The Lease Query LEG receives the
request and queries the DHCP server. If the server finds a match for the IP address in its database, the
server replies with the subscriber information (3). Based on the received information, the LEG responds
to the SCE with a pull-response, which includes the subscriber ID and the IP address lease-time returned
from the DHCP server (4).
Note An Internet Engineering Task Force (IETF) standard defines the DHCP Lease-Query transaction. The
LEG supports the RFC 4388 standard. For more information, see the IETF website.

• DHCP Lease Query LEG Process, page 7-3
• DHCP Lease Query Transaction, page 7-3
• Installation and Usage, page 7-4
DHCP Lease Query LEG Process

The LEG processes DHCP Lease-Query transactions to the DHCP server using the IP address indicated
in the pull-request from the SCE. The DHCP server replies whether there is an active lease
(DHCPLEASEACTIVE message) for this IP address and provides information about the subscriber
associated with this IP address according to a list of options requested by the LEG. By default, the LEG
requests the lease time and the modem MAC and adds package association related options if needed.
The DHCP Lease Query LEG supports up to two redundant DHCP servers. The LEG identifies a server
failure by counting the consecutive requests that time out. After a configurable threshold of timed-out
requests, the LEG starts to send the requests to the recently activated server, which was previously in
standby. The LEG does not return to the failed server until the activated server fails.
When installing the LEG on the SM server, it runs with the privileges assigned to the user pcube on this
machine. On UNIX platforms, because only the super-user (root) can open ports under 1024, the LEG
cannot open the DHCP ports. To solve this problem, a simple application is supplied with the LEG,
which forwards the DHCP packets between the LEG and the DHCP servers. This application is the
DHCP Forwarder, which is described in the DHCP Forwarder Application module.
When installing the LEG on the SCE device, there is no need to use the DHCP Forwarder application.
DHCP Lease Query Transaction

The DHCP Lease Query transaction is a DHCP transaction where the client (LEG) sends a
DHCPLEASEQUERY message to the server, indicating the information it wants to query. The LEG only
queries the IP address. The server can reply with several types of messages; for example a
DHCPLEASEACTIVE message means that an active lease was found and the request information is
supplied, or a DHCPLEASEUNASSIGNED message means this IP is currently not assigned to any
subscriber.
The following is a detailed description of the attributes extracted from the DHCP Lease Query
transaction:

OL-15752-01 7-3
• Subscriber ID—By default, the subscriber ID is the modem MAC address, which you extract from
option 82 (Remote ID sub-option of the DHCP Relay Agent Information Option). Therefore, the
DHCP server must support and store option 82 for each Customer Premise Equipment (CPE). This
default can be overwritten by configuration. Furthermore, the LEG can assign the IP address as a
fallback if the option does not exist in the server's response. This fallback is disabled by default.
• Lease time—The assigned IP is added to the SM or SCE database with a lease time taken from
option 51. Note that if option 51 does not appear in the DHCPLEASEACTIVE reply, an infinite
lease time is assigned for this IP address.
• Package—Configurable options in the DHCP message determine how to assign the package
information. The LEG includes a component that converts the package information data from the
DHCP packet to a subscriber package ID. If the packet does not contain package information, it is
possible to log in the subscriber with a default package, or log in the subscriber with no package
information at all. The package options are assumed to be encoded as strings.
After extracting the preceding information, the LEG logs the subscriber into the SM/SCE.
Installation and Usage

The DHCP Lease Query LEG is an external component (PQI file) that can be installed on the SM or SCE
device.
For information about installing and using the DHCP Lease Query LEG on the SM, see Subscriber
Manager Integration and Subscriber Manager Integration - Configuration. For information about
installing and using the DHCP Lease Query LEG on the SCE, see SCE Integration and SCE Integration
- Configuration.
Package Contents
The DHCP Lease Query LEG distribution is part of the SM LEG distribution. The DHCP Forwarder
application distribution and installation script are also part of the SM LEG distribution.
The DHCP Lease Query LEG uses the DHCP Forwarder application on UNIX machines. For more
information, see DHCP Forwarder Application, page 12-1.
The LEG installation package includes a set of configuration files and command-line utilities for the
LEG.
The SCMS SM LEG distribution file contains the DHCP Lease Query LEG distribution, which is located
in the Lease_Query_LEG directory. Cisco supplies a DHCP Lease Query LEG distribution package. The
following table describes the package contents:
Table 7-1 File Layout of the DHCP Lease Query LEG Distribution Package

pkg-ext-dir
Install LEG installation
procedure description
install-forwarder.sh DHCP Forwarder
installation script
linux-def.sh Linux-specific
definitions

7-4 OL-15752-01
Table 7-1 File Layout of the DHCP Lease Query LEG Distribution Package (continued)

solaris-def.sh Solaris-specific
definitions
dhcp_forwarder.tar.gz DHCP Forwarder
distribution
sm-common.sh General utility script
sce
dhcp_pkg.cfg Default configuration
file for package
association
leaseq.pqi DHCP Lease Query
LEG distribution
sm
leaseq.pqi DHCP Lease Query
LEG distribution
Note The directory to which the distribution is extracted is referred to as pkg-ext-dir.

OL-15752-01 7-5

7-6 OL-15752-01
CH A P T E R 8
Subscriber Manager Integration
This module describes the procedures for installing, uninstalling, and upgrading the DHCP Lease Query
LEG on the subscriber manager (SM).
Note This module is relevant if you are using the subscriber manager server on your network. You should
install the DHCP Lease Query LEG on the SM server and not on the service control engine (SCE) device.
• Installing the DHCP Lease Query LEG on the SM, page 8-1
• Uninstalling the DHCP Lease Query LEG from the SM Server, page 8-2
• Upgrading the DHCP Lease Query LEG, page 8-2
Installing the DHCP Lease Query LEG on the SM

Step 1 Install the DHCP Forwarder application
The DHCP Forwarder application bridges between the LEG and the DHCP server. See Installing the
DHCP Forwarder, page 12-1.
Step 2 Install the PQI file of the DHCP Lease Query LEG
Run the p3inst command-line utility (CLU) from the SM CLU directory ~pcube/sm/server/bin
>p3inst --install -f leaseq.pqi
Note After the installation of the PQI file, the SM restarts itself automatically.
Step 3 Edit the DHCP Lease Query LEG configuration files

The DHCP Lease Query LEG includes two configuration files under ~pcube/sm/server/root/config:
• leaseq.cfg—Configures general attributes of the LEG
• dhcp_pkg.cfg—Configures rules for policy assignment
It is recommended to edit the files according to the configuration required at first use.
Step 4 Edit the SM configuration file p3sm.cfg and set the subscriber introduction mode to be pull mode
[SM General]
# The following parameter defines whether the SM introduces
# the subscribers to
# the SCEs immediately after the subscriber's

OL-15752-01 8-1
Chapter 8 Subscriber Manager Integration
Uninstalling the DHCP Lease Query LEG from the SM Server
# login operation (push-mode) or when the SE requests

# subscriber information specifically (pull-mode).
# Optional values: [pull, push]. Default: push.
introduction_mode=pull
Step 5 Load the configuration files to the SM using the p3sm CLU
This command-line utility loads the new configuration to the SM and activates it.
>p3sm --load-config
Step 6 Add a resource to the Veritas Cluster Server
This can be done only on SM Cluster setups. To add a resource, see Adding a DHCP Forwarder
Resource, page 12-2.
Uninstalling the DHCP Lease Query LEG from the SM Server

Step 1 Run the p3inst command-line utility from the SM CLU directory ~pcube/sm/server/bin
>p3inst --uninstall -f leaseq.pqi
Note After the uninstall process, the SM restarts itself automatically.
Step 2 Uninstall the DHCP Forwarder Veritas Cluster Agent.

This can be done only on SM Cluster setups. See Removing a DHCP Forwarder Resource, page 12-4.
Step 3 Uninstall the DHCP Forwarder application. See Uninstalling the DHCP Forwarder, page 12-2.
Upgrading the DHCP Lease Query LEG

The DHCP Lease Query LEG must be upgraded as part of the SM upgrade process, because previous
versions of the DHCP Lease Query LEG are incompatible with the SM 3.x version. The upgrade for the
DHCP Lease Query LEG should be performed together with the upgrade process of the SM.
Step 1 Backup the configuration files of the DHCP Lease Query LEG.
The original configuration files are deleted by the uninstall process in the next step.
Step 2 Uninstall theDHCP Lease Query LEG by running the p3inst CLU
>p3inst --uninstall -f lease-query-pqi
Note After the uninstall process, the SM restarts automatically.
Step 3 Perform an upgrade of the SM

The SM upgrade procedure is described in the Cisco SCMS Subscriber Manager User Guide.
Step 4 Install the new version of the DHCP Lease Query LEG by running the p3inst CLU
>p3inst --install -f lease-query-pqi
Step 5 Restore the configuration files of the DHCP Lease Query LEG

8-2 OL-15752-01
Step 6 Load the new configuration of the SM by running the p3sm CLU
>p3sm --load-config

OL-15752-01 8-3

8-4 OL-15752-01
CH A P T E R 9
Subscriber Manager Integration - Configuration
This module describes how to configure the DHCP Lease Query LEG on the subscriber manager and
how to use the command-line utilities (CLU).
Note This module is relevant if you are using the subscriber manager server on your network. You should
install the DHCP Lease Query LEG on the SM server and not on the service control engine (SCE) device.
Information About Configuring the DHCP Lease Query LEG

The DHCP Lease Query LEG on the SM is configured using two configuration files: leaseq.cfg (general
configuration) and dhcp_pkg.cfg (dynamic package association), which reside in the
~pcube/sm/server/root/config directory.
The configuration files consist of sections headed by a bracketed section title; for example,
[DHCP-Lease-Query-LEG]. Each section consists of several parameters having the format
parameter=value. The number sign (“#”) at the beginning of a line signifies that it is a remark.
• Configuring the DHCP Lease Query LEG, page 9-1
• Configuring Policy Association, page 9-4
• Information About the DHCP Lease Query LEG CLU, page 9-7
Configuring the DHCP Lease Query LEG

The following is a description of the configuration variables of leaseq.cfg.
The [DHCP-Lease-Query-LEG] section contains the following parameters:
• start
Defines whether the SM runs the DHCP Lease Query LEG at startup.
Possible values for this parameter are yes and no. The default value is no.
To run the LEG, this parameter must be set to yes.
• max_concurrent_sessions
Defines the number of concurrent sessions the LEG should support. This parameter limits the
resources used by this module.
Possible values for this parameter are integers. The default value is 256.

OL-15752-01 9-1
Chapter 9 Subscriber Manager Integration - Configuration
• dhcp_servers
Defines to which DHCP servers the LEG can send requests.
You must enter the IP addresses or hostnames of the DHCP servers separated by commas.
• server_port
Defines the UDP port to which the DHCP servers listen and the Lease Query messages are sent. It
is recommended to use 9067 when working with the DHCP Forwarder. The default value is 9067.
• listening_port
Defines the UDP port to which the LEG listens and the Lease Query replies are sent. It is
recommended to use 9068 when working with the DHCP Forwarder. The default value is 9068.
• client_port
Defines the UDP port that the LEG uses when sending Lease Query messages to the DHCP servers.
It is recommended to use 8068 when working with the DHCP Forwarder. The default value is 8068.
• client_ip_address
Defines the source IP address of the lease-query packets sent to the DHCP servers. The giaddr field
of the DHCP packet also uses this IP address. This parameter is useful for machines with multiple
network interfaces.
The default value is the loopback IP address of the machine.
• support_auto_logout
Defines whether the LEG should query the DHCP servers whenever the autologout mechanism
identifies an expired lease.
Possible values for this parameter are true and false. The default value is false.
• use_forwarder
Defines whether the LEG utilizes the DHCP Forwarder application on the local machine.
Possible values for this parameter are true and false. The default value is true.
• fail_over_criteria
Defines the number of consecutive request failures (timeouts) that triggers a fail-over. Since the
queries are not answered when the server fails, these queries will time out. The consecutive
timed-out queries are counted and when they reach this threshold, the second server is set as the
active server. The default value is 3.
Note The session_timeout parameter affects how long it will take to detect a failed server. Only when the
configured amount of queries fail will the fail-over process be triggered.
• log_timed_out_queries
Controls log messages regarding timed-out queries.
Possible values for this parameter are true or false. The default value is true.
• log_failed_queries
Controls log messages regarding queries that are not sent.
• log_all_queries
Controls log messages regarding each query sent and any reply received.

9-2 OL-15752-01
Possible values for this parameter are true or false. The default value is false.
Use this parameter only for troubleshooting.
• log_login_failures
Controls log messages regarding replies that did not result in the login of a subscriber to the SM.
The [Subscriber ID] section defines the functionality of how the LEG handles the subscriber ID. The
subscriber ID can be taken from a DHCP option, with the ability to fallback to using the allocated IP
address as the subscriber ID. This section contains the following parameters:
• dhcp_option
Defines which DHCP option to use as the subscriber ID. The format of this parameter is the option
number itself; or for DHCP options that have sub-options, the format is the DHCP option and
sub-option type, separated by a colon. For example: 43:123 or 61. The default value is 82:2
(Relay-Agent-Information using the Remote-ID information).
• dhcp_option_type
Defines the format type of the DHCP option defined by the dhcp_option parameter.
Optional values are binary, indicating a binary string converted to an ASCII hexadecimal string; or
string, indicating an ASCII string. The default value is binary.
• default_id
Defines whether in cases where the dhcp_option is not found in the DHCP packet, the LEG should
fall back to a different way of defining the subscriber ID. The supported fallbacks are:
– ip—Use the allocated IP address to create a subscriber ID in the format of: IP_aaa.bbb.ccc.ddd
– Not setting this parameter—No fallback. No login will be performed.
• By default, this parameter is not set.
The [DHCP-Lease-Query-Ids] section contains the message type numbers of the different Lease Query
transaction message types. This is necessary, because the DHCP Lease Query definition is an IETF draft.
This section contains the following parameters:
• lease_query
Defines the DHCPLEASEQUERY message type value. The default value is 13.
• lease_active
Defines the DHCPLEASEACTIVE message type value. The default value is 16.
The following is a sample configuration file:
[DHCP-Lease-Query-LEG]
start=yes
dhcp_servers = 198.1.2.3, 198.5.6.7
fail_over_criteria=10
session_timeout=10
log_timed_out_queries=true
log_failed_queries=true
log_all_queries=true
log_login_failures=true
[Subscriber ID]
dhcp_option=44
dhcp_option_type=binary
[DHCP-Lease-Query-Ids]
lease_query=13
lease_active=16

OL-15752-01 9-3
Configuring Policy Association
Note The configuration described in this section is optional.
The subscriber policy configuration in the DHCP Lease Query LEG can be handled in one of the
following ways:
• Dynamic assignment of policy information using information extracted from the DHCP packet. See
Dynamic Assignment of Policy Information, page 9-4.
• Static assignment of a constant package ID for all subscribers who log on via the DHCP Lease Query
LEG. See Static Assignment of Policy Information, page 9-7.
Dynamic Assignment of Policy Information

Dynamic assignment of policy information is supported when policy information is submitted in the
DHCP packets. The LEG concatenates the desired options and creates a policy-name. It is possible to
map, using the configuration, between the policy-names and the application policy parameters such as
package IDs and Virtual-links. The DHCP Lease Query LEG can support multiple policies.
To extract the policy information data from the DHCP packet, use the dhcp_pkg.cfg configuration file
to define the option types that contain the policy information and define the conversion map of the
policy-names to the package IDs (or any other policy) of the Service Control Application for Broadband
(SCA BB).
The LEG is able to add additional data to the login operation based on the LEG configuration. This data
is added as a key-value pair. Other modules in the login chain can use this data, such as the SOAP LEG
(see the SOAP LEG section). This data can be created by concatenating the data of several DHCP options
and can be given a user-defined label.
The [DHCP.Policy.XXX] sections contain the following parameters:
• options_order_for_policy_name
Defines the DHCP options that contain the policy association information and defines the order of
concatenation of the data. The DHCP header field called giaddr (Relay-Agent IP) is also supported;
it requires the use of the type integer in the option_type parameter.
This parameter has no default value.
The format is: option[:subtype],option[:subtype],giaddr
• options_type
Defines the format type of the DHCP options and fields defined by the
options_order_for_policy_name parameter.
Possible values for this parameter are binary (a binary string that is converted to an ASCII
hexadecimal string), string (an ASCII string), or integer (a 4-byte integer converted to an IP
address string in dotted notation). Order the list in the same way as
options_order_for_policy_name.
• name_seperator_value
Defines the separator character to use between two options when concatenating them to each other
to create the policy name. Any character is accepted. The default value is '_'.

9-4 OL-15752-01
• use_default
Determines whether to use a default policy when no policy information can be extracted from the
DHCP data, such as the configurable options are missing or no options were configured.
• default_policy
Defines the default policy ID to use if no policy information is extracted from the DHCP data. This
parameter is relevant only if the use_default parameter is set to true.
Possible values for this parameter are any integer number. This parameter has no default value.
• allow_login_with_no_policy
Defines whether to perform a login without policy information when no policy information can be
extracted from the DHCP data and the use_default parameter is set to false.
This parameter is relevant only if the use_default parameter is set to false.
• policy_property_name
Defines the name of the application property that contains the policy information. This parameter
has no default value.
Note The policy_property_name parameter is case sensitive and must be written exactly as defined by the
SCA BB Console. For example, packageId, monitor, upVlinkId, or downVlinkId.
• log_all
Defines whether to write detailed user-log messages for all policy association events.
• log_default_assignment
Defines whether to write a user-log message for every assignment of the default value (as defined
by the default_policy parameter).
• mapping_table.<policy_name>
Multiple entries containing the information to convert from the policy information as it appears in
the DHCP packet to the policy property value to be used by the SCA BB application.
These entries do not have default values.
Note The policy_name is case sensitive and must be written exactly as it exists in the DHCP packets.
The [Additional Data] section of the configuration file contains the following parameters:
• label_options
Defines which DHCP option to extract to add to the login operation.
Possible values are the option number or, in the case of DHCP options with sub-options, the option
and sub-option separated by a colon. For example, 43:123 or 61.
There is no default value for this parameter.

OL-15752-01 9-5
• label_keys
Defines the keys that should mark the DHCP options defined by the label_options parameter.
• label_options_type
Defines the format type of the DHCP option defined by the label_options parameter.
hexadecimal string) or string (an ASCII string).
The default value is binary.
Dynamic Assignment of Policy Information Example

Suppose that the policy information appears inside option 43 (Vendor Specific Option) of the DHCP
packet and that both subtypes, 102 and 101, are in use. Configure the options_order_for_policy_name
parameter as follows:
options_order_for_policy_name=43:102,43:101
Suppose that option 43 with subtype 102 contains the type of package (gold, silver, or bronze), and that
option 43 with subtype 101 contains domain information (the package type has a different meaning in
different domains). If the separator value is configured to the default value, configure the mapping_table
entries as follows:
mapping_table.gold_domain1=11
mapping_table.silver_domain1=13
This configuration means that if the DHCP packet contains the value 'gold' inside option 43 with subtype
102, and the value 'domain1' inside option 43 with subtype 101, the package ID that will be associated
to the subscriber in the SM will have the value 11.
The following configuration describes how to add the data of the Relay-Agent Circuit-Id option as
additional data to the login operation:
[Additional Data]
label_options=82:1
label_keys=PORT_ID
label_options_type=string
The following is an example of the entire configuration file:
[DHCP.Policy.Package]
name_separator_value=_
use_default=true
default_policy=1
policy_property_name=packageId
allow_login_with_no_policy=false
log_all=false
log_default_assignment=false
[Additional Data]
label_options=82:1
label_keys=PORT_ID
label_options_type=string

9-6 OL-15752-01
Static Assignment of Policy Information

If the installation does not require dynamic assignment of package information, the configuration file
dhcp_pkg.cfg should define the default package ID and default Virtual-Link to be assigned to all the
subscribers, as shown in the following example:
use_default=true
default_policy=1
[DHCP.Policy.VirtualLinkDownstream]
policy_property_name=downVlinkId
use_default=true
default_policy=0
[DHCP.Policy.VirtualLinkUpstream]
policy_property_name=upVlinkId
use_default=true
default_policy=0
All other configuration parameters should not be set.
Information About the DHCP Lease Query LEG CLU

The p3leasequery command-line utility (CLU) displays the DHCP Lease Query LEG configuration,
status, and statistics. The command format is p3leasequery <operation>.
The following table lists the p3leasequery operations.
Table 9-1 p3leasequery Operations
Operation Description
--show Displays all of DHCP Lease Query LEG
configurations and status
--show-statistics Displays counters of DHCP messages handled and
number of logon operations performed
--show-version Displays the version number of the DHCP Lease
Query LEG
--help Displays a list of available operations and
arguments with a short explanation of their
meanings
• Viewing the DHCP Lease Query LEG Status, page 9-7

• Viewing the DHCP Lease Query LEG Statistics, page 9-8
• Viewing the DHCP Lease Query LEG Version, page 9-8
Viewing the DHCP Lease Query LEG Status

The following is an example using the p3leasequery CLU with the show operation:

OL-15752-01 9-7
>p3leasequery --show
DHCP Lease-Query LEG:
=====================
Active: true
DHCP Servers:
Active: 10.1.2.3
Standby: N/A
Session timeout: 20
Fail over criteria: 3
Subscriber ID:
Option: 82:2
Format: binary
Fallback: none
Command terminated successfully
>
Viewing the DHCP Lease Query LEG Statistics

The following is an example of the p3leasequery CLU using the show-statistics operation:
>p3leasequery --show-statistics
DHCP Lease-Query LEG Statistics:
================================
Lease-Queries Sent: 16
Lease-Queries Replied: 16
Active Lease Replies: 16
Non-Active Lease Replies: 0
Total timed-out sessions: 0
Consecutive timed-out sessions: 0
Number of fail-overs 0
Invalid Replies: 0
Sessions in process: 0
Max-Concurrent sessions: 3
>
Viewing the DHCP Lease Query LEG Version

The following is an example of the p3leasequery CLU using the show-version operation:
>p3leasequery --show-version
DHCP LEASE QUERY LEG 3.1.0 Build 176
>

9-8 OL-15752-01
CH A P T E R 10
SCE Integration
Note This section is relevant if you intend to install the DHCP Lease Query LEG directly on the service
control engine (SCE) device in an SM-less installation.
This module describes the procedures for installing, uninstalling, and upgrading the DHCP Lease Query
LEG on the SCE.
The SM-less integration supports a cascade SCE installation.
• Installing the DHCP Lease Query LEG on the SCE, page 10-1
• Uninstalling the DHCP Lease Query LEG from the SCE Device, page 10-1
• Upgrading the DHCP Lease Query LEG, page 10-2
Installing the DHCP Lease Query LEG on the SCE

Step 1 Install the PQI file of the DHCP Lease Query LEG.
Run the following CLI on the SCE device:
SCE2000#>configure
SCE2000(config)#>interface LineCard 0
SCE2000(config if)#>pqi install file LEG-PQI
Note After the installation of the PQI file, the management agent restarts itself automatically. Please wait until
the management agent is up before proceeding with configuring the LEG.
Step 2 Configure the LEG using the SCE CLI.

Before you start using the LEG, you must configure the DHCP servers and start the LEG operation. See
the Configuration CLI for more details.
Uninstalling the DHCP Lease Query LEG from the SCE Device
Step 1 Uninstall the DHCP Lease Query LEG using the CLI on the SCE device.

OL-15752-01 10-1
Chapter 10 SCE Integration
Run the following CLI on the SCE device.

SCE2000#>configure
SCE2000(config if)#>pqi uninstall file LEG-PQI
Note After the uninstallation of the PQI file, the management agent restarts itself automatically. Please wait
until the management agent is up before using the SCE device.

The DHCP Lease Query LEG must be upgraded as part of the SCE upgrade process, because previous
versions of the DHCP Lease Query LEG are incompatible with the SM 3.x version. The upgrade for the
DHCP Lease Query LEG should be performed together with the upgrade process of the SCE.
Step 1 Backup the configuration files of the DHCP Lease Query LEG.
The files to backup are leaseq.cfg and dhcp_pkg.cfg, which both reside in the
~pcube/sm/server/root/config directory.
Step 2 Uninstall the DHCP Lease Query LEG.
SCE2000#>configure
SCE2000(config if)#>pqi uninstall file LEG-PQI
Note After the uninstallation of the PQI file, the management agent restarts itself automatically. Please wait
until the management agent is up before using the SCE device.
Step 3 Perform an upgrade of the SCE.

The SCE upgrade procedure is described in the Cisco SCE Software Configuration Guide.
Step 4 Install the new version of the DHCP Lease Query LEG.
SCE2000#>configure
SCE2000(config if)#>pqi install file LEG-PQI
Note After the installation of the PQI file, the management agent restarts itself automatically. Please wait until
the management agent is up before proceeding with configuring the LEG.
Step 5 Configure the LEG using the SCE CLI.

10-2 OL-15752-01
CH A P T E R 11
SCE Integration - Configuration
This module describes how to configure the DHCP Lease Query LEG on the SCE and the CLI.
• Configuring the DHCP Lease Query LEG on the SCE, page 11-1
• Information About the DHCP Lease Query LEG CLI, page 11-1
Configuring the DHCP Lease Query LEG on the SCE

The DHCP Lease Query LEG on the SCE is configured using the CLI.
Information About the DHCP Lease Query LEG CLI

• Configuration CLI, page 11-1
• Show CLI, page 11-2
Configuration CLI
Use the Command-Line Interface (CLI) to configure the general LEG settings of the DHCP Lease Query
LEG.
To enable the LEG:
SCE(config)# subscriber LEG dhcp-lease-query
To disable the LEG:

SCE(config)# no subscriber LEG dhcp-lease-query
To set the IP addresses of the DHCP servers (one or two addresses):

SCE(config)# subscriber LEG dhcp-lease-query servers STRING STRING
To reset the DHCP servers:
SCE(config)# no subscriber LEG dhcp-lease-query servers
To set the session_timeout configuration variable (see also Information About Configuring the DHCP
Lease Query LEG, page 9-1):
SCE(config)# subscriber LEG dhcp-lease-query session-timeout DECIMAL
To set the session_timeout variable to the default value:

OL-15752-01 11-1
Chapter 11 SCE Integration - Configuration
SCE(config)# default subscriber LEG dhcp-lease-query session_timeout
The failover criteria configuration variable defines the number of consecutive request failures (timeouts)
that triggers a fail-over. Because the queries are not answered when the server fails, these queries time
out. The consecutive timed-out queries are counted and when they reach this threshold, the second server
is set as the active server. The default value is 3.
To set the fail_over_criteria:
SCE(config)# subscriber LEG dhcp-lease-query failover-criteria DECIMAL
To set the fail_over_criteria variable to the default value:

SCE(config)# default subscriber LEG dhcp-lease-query failover-criteria
The format of the subscriber ID can be set to binary or string. Setting the subscriber ID to binary
indicates a binary string converted to an ASCII hexadecimal string. Setting it to string indicates an
ASCII string. Use the ip-fallback parameter to set the IP to be the subscriber ID if the DHCP option is
not found in the packet.
To set the subscriber ID option:
SCE(config)# subscriber LEG dhcp-lease-query sub-id-option STRING binary|string
[ip-fallback]
For example:
• subscriber LEG dhcp-lease-query sub-id-option 82:2 binary
This example uses DHCP option 82:2 for the subscriber ID, and its type is binary. No fallback is
performed if the option is not found.
• subscriber LEG dhcp-lease-query sub-id-option 43:1 string ip-fallback
This example uses DHCP option 32:1 for the subscriber ID, and its type is string. The IP is used as
the subscriber ID if the DHCP option is not found.
To set the subscriber ID option to the default value:
SCE(config)# default subscriber LEG dhcp-lease-query sub-id-option
For policy association, the LEG uses exactly the same file described in the Configuring Policy
Association section. Set and load the configuration file with the following CLI (you must specify the full
path and the file name):
SCE(config)# subscriber LEG dhcp-lease-query package-association-file STRING
The default package association configuration does not assign package information. To set the
configuration back to the default configuration file:
SCE(config)# default subscriber LEG dhcp-lease-query package-association-file
To set all parameters of the DHCP lease query LEG to the default settings, use the following CLI:
SCE(config)# default subscriber LEG dhcp-lease-query
Show CLI
To view the general configuration of the LEG, enter the following command:
SCE# show subscriber LEG dhcp-lease-query
To view the statistics counters of the LEG:

11-2 OL-15752-01
SCE# show subscriber LEG dhcp-lease-query counters
To reset the statistics counters of the LEG:

SCE# clear subscriber LEG dhcp-lease-query counters

OL-15752-01 11-3

11-4 OL-15752-01
CH A P T E R 12
DHCP Forwarder Application
This module describes how to install the DHCP forwarder application as well as adding and removing
resources.
Note This module is only relevant when the DHCP Lease Query LEG is installed on the subscriber manager
server.
The DHCP Forwarder application acts as a bridge between the DHCP Lease Query LEG and the DHCP
servers. The LEG sends a request to the DHCP Forwarder, which then forwards the request to the
appropriate DHCP server. The DHCP Forwarder passes the replies from the DHCP servers to the LEG.
The LEG signals the forwarder which server should receive each request. Therefore, no special
configuration is needed for this application.
Because only root privileged applications can open ports under 1024 (DHCP uses ports 67 and 68), the
DHCP Forwarder runs with root privileges.
• Installing the DHCP Forwarder, page 12-1
• Uninstalling the DHCP Forwarder, page 12-2
• DHCP Forwarder VCS Agent, page 12-2
Installing the DHCP Forwarder
Step 1 Run the DHCP Forwarder installation script from the Lease_Query_LEG directory of the SM DIST root
directory.
You must run the DHCP Forwarder installation script as root.
#./install-forwarder.sh
The installation script extracts the DHCP Forwarder distribution to the sm-inst-dir
\sm\server\addons\dhcp-forwarder directory (sm-inst-dir refers to the SM installation directory). The
script adds the initialization scripts to their location according to the machine's OS.
Step 2 Run the DHCP Forwarder application.
The DHCP Forwarder application can be run using one of the following methods:
• Restart the machine. The initialization script will start the application automatically.
• Run the following command as root:

OL-15752-01 12-1
Chapter 12 DHCP Forwarder Application
Uninstalling the DHCP Forwarder
#/etc/init.d/p3dhcpforwarder start
Note It is not possible to run the script if the /etc/motd file exists. The file should be moved or removed prior
to running the install-forwarder.sh script.
Uninstalling the DHCP Forwarder
Step 1 Stop the DHCP Forwarder application.

Run the following command as root to stop the application.
#/etc/init.d/p3dhcpforwarder stop
Step 2 Remove the DHCP Forwarder application startup and shutdown scripts.
Run the following command as root to remove the startup and shutdown scripts.
• For Solaris:
# rm /etc/rc*.d/[SK]*p3dhcpforwarder
# rm /etc/init.d/p3dhcpforwarder
• For Red Hat:
# rm /etc/rc.d/rc*.d/[SK]*p3dhcpforwarder
# rm /etc/rc.d/init.d/p3dhcpforwarder
Step 3 Remove the DHCP Forwarder application directory.
Run the following command to remove the application.
# rm -r ~pcube/sm/server/addons/dhcp-forwarder
DHCP Forwarder VCS Agent

To verify that the DHCP Forwarder process is active at all times, a Veritas Cluster Server (VCS) Agent
of type OnOnlyProcess is added as a resource.
• Adding a DHCP Forwarder Resource, page 12-2
• Removing a DHCP Forwarder Resource, page 12-4
Adding a DHCP Forwarder Resource
Step 1 Import the OnOnlyProcess agent's type from the

/opt/VRTSvcs/bin/OnOnlyProcess/OnOnlyProcess.cf file.
Step 2 Add an OnOnlyProcess resource called DHCP_Forwarder to the service group.
Step 3 Note the path and arguments of the DHCP Forwarder.

12-2 OL-15752-01
Run the following command via a Telnet session on each of the servers:
>ps -ea -o pid,s,args
Look for the line containing the text "DHCP_FORWARDER". This line contains the path and arguments
of the DHCP Forwarder to be used in the next step.
Step 4 Define the OnlineCmd, PathName, and Arguments parameters.
Define the parameters as follows:
• OnlineCmd—Type the DHCP Forwarder start command:
/etc/init.d/p3dhcpforwarder start
• PathName—Type the DHCP Forwarder process path (from the previous step). For example:
/opt/pcube/j2re1.4.2_05/bin/java
• Arguments—Type the DHCP Forwarder process arguments (from the previous step). For example:
DAPP=DHCP_FORWARDER -jar /opt/pcube/sm/server.
For further information about the parameters, see the following figure.
Figure 12-1 Adding a DHCP Forwarder Resource
Note The arguments line might seem shorter than the actual full argument list. This is perfectly acceptable.

OL-15752-01 12-3
Removing a DHCP Forwarder Resource
Step 1 Right-click on the DHCP Forwarder Resource icon and choose Delete from the drop-down menu.
Figure 12-2 Removing a DHCP Forwarder Resource

12-4 OL-15752-01
P A R T 3
SCE-Sniffer DHCP LEG

CH A P T E R 13
About the SCE-Sniffer DHCP LEG
This module describes the Service Control Management Suite (SCMS) Subscriber Manager (SM)
SCE-Sniffer DHCP Login Event Generator (LEG) software module.
• Information About the SCE-Sniffer DHCP LEG, page 13-1
• Information About SCE-Sniffer DHCP LEG Functionality, page 13-2
Information About the SCE-Sniffer DHCP LEG

The SCMS SM SCE-Sniffer DHCP LEG is a software module that receives Raw Data Record (RDR)
messages containing DHCP information from Service Control Engine (SCE) devices configured with a
DHCP sniffer service. The SCE-Sniffer DHCP LEG is an extension of the SM software and runs as part
of the SM.
SCE-Sniffer DHCP LEG Operation

The SCE device analyzes DHCP traffic and reports the DHCP transactions to the SM device using the
RDR protocol. The SM extracts the modem MAC address, the CPE IP address, and optionally, the
subscriber package information from the RDR, and triggers a logon or logout operation to the SM.
Figure 13-1 represents the operation of the SCE-Sniffer DHCP LEG:

OL-15752-01 13-1
Chapter 13 About the SCE-Sniffer DHCP LEG
Information About SCE-Sniffer DHCP LEG Functionality
Figure 13-1 SCE-Sniffer DHCP LEG Operation
SCE
Traffic (1)
RDR(2)
Login
Logout (3)
SCE-
Sniffer SM
DHCP
157081
LEG

The SCE devices analyze the DHCP ACK packets of DHCP transactions and send the information to the
SCE-Sniffer DHCP LEG that resides on the SM. The LEG performs login and logout operations to the
SM using the information sent from the SCE devices. The DHCP transactions that are relevant for the
operation of the LEG are initial logon, lease extension, and release.
• DHCP Initial Logon Transaction, page 13-2
• DHCP Lease Extension Transaction, page 13-3
• DHCP Release Transaction, page 13-3
DHCP Initial Logon Transaction

The following is a detailed description of the attributes extracted from the DHCP initial logon
transaction:
• Subscriber ID
For cable environments—The subscriber ID is the modem MAC address, which you extract from
option 82 (Remote-ID sub-option of the DHCP Relay Agent Information Option). Therefore, for a
successful logon operation, it is required that option 82 contains the modem MAC address in the
DHCP initial logon transaction. If option 82 is missing, it is not possible to perform a logon
operation. Furthermore, the value of option 82 is compared with the haddr field to identify modem
transactions and not login the modem IP address to the SM.
For non-cable DHCP environments—The LEG supports using other DHCP options for the
subscriber ID. If the DHCP option does not exist in the packet, it is possible to use the IP address
as a fallback. In this case, the subscriber ID is in the format IP_a.b.c.d.
The chain of decisions regarding the subscriber-ID is as follows:
a. Use the configured DHCP option as the subscriber-ID if it exists.

13-2 OL-15752-01
b. Otherwise, if the fallback to IP is enabled, use the IP address.

c. Otherwise, attempt to extend the lease based solely on the IP address. (This will only work if
the IP address is in the database).
• IP address
Each subscriber might have multiple IP addresses, depending on the number of CPE devices
connected to the modem. A logon operation is triggered for each assigned IP address in the DHCP
message.
If the transaction correlates to a CPE device, the assigned IP address for that CPE device is added
to the SM database. The IP address of the modem is not added to the SM database. If the transaction
correlates to a modem device, no IP mappings are added to the SM database, but a logon operation
is performed anyway to update package information.
• Lease time
If the transaction correlates to a CPE device, the assigned IP is added to the SM database with a
lease time taken from option 51 (lease time option). Note that option 51 must contain the lease time;
otherwise no logon operation is performed.
• Policy
The policy information is assigned according to configurable options in the DHCP message. The
LEG includes a component that converts the package information data from the DHCP packet to a
subscriber package ID. If the packet does not contain package information, it is possible to log in
the subscriber with a default package, or log in the subscriber with no package information at all.
After extracting the above information, the LEG performs a logon operation to the SM.
DHCP Lease Extension Transaction

The same attributes are extracted from the DHCP lease extension transaction as for the DHCP initial
logon transaction, but the existence of option 82 is not required. If the modem MAC address cannot be
retrieved from option 82, the SM database is queried for this information.
DHCP Release Transaction

The DHCP release transaction is handled differently to the other DHCP transactions. If the transaction
correlates to a CPE device, the LEG performs an SM logout operation with the IP address of the CPE,
which appears as a released IP address in the packet itself.
Note A logout operation is also performed when the lease time of the subscriber is expired, and the SM is
configured to perform auto logouts. Release transactions also trigger logout operations, but do not
replace the auto logout mechanism of the SM.

OL-15752-01 13-3

13-4 OL-15752-01
CH A P T E R 14
Installing the SCE-Sniffer DHCP LEG
This module describes the procedures for installing, uninstalling, and upgrading the SCE-Sniffer DHCP
login event generator (LEG) on the subscriber manager (SM).
The SCE-Sniffer DHCP LEG is an external component (PQI file) of the SM software and should be
installed separately using the SM Command-Line Utility (CLU). The SCE-Sniffer DHCP LEG
distribution is part of the SM LEG distribution.
The installation package of the LEG includes a set of configuration files and CLU commands for the
SCE-Sniffer DHCP LEG.
• Installing the SCE-Sniffer DHCP LEG, page 14-1
• Uninstalling the SCE-Sniffer DHCP LEG, page 14-2
• Upgrading the SCE-Sniffer DHCP LEG, page 14-2
Installing the SCE-Sniffer DHCP LEG
Prerequisites
Verify that the Service Control Application for Broadband (SCA BB) is installed on all SM and SCE
devices. If not, install the application as described in the Cisco Service Control Application for
Broadband User Guide.
Step 1 Install the PQI file of the SCE-Sniffer DHCP LEG

Run the p3inst command-line utility (CLU) from the SM CLU directory ~pcube/sm/server/bin
>p3inst --install -f dhcpsnif.pqi
Note After the installation of the PQI file, the Subscriber Manager restarts automatically.
Step 2 Edit the SCE-Sniffer DHCP LEG configuration files.

The SCE-Sniffer DHCP LEG includes two configuration files under ~pcube/sm/server/root/config:
• dhcpsnif.cfg—Configures general attributes of the LEG
• dhcp_pkg.cfg—Configures rules for package assignment

OL-15752-01 14-1
Chapter 14 Installing the SCE-Sniffer DHCP LEG
Uninstalling the SCE-Sniffer DHCP LEG
Note It is recommended to familiarize yourself with these files immediately after the first installation and edit
them according to your specific needs. See Configuring the SCE-Sniffer DHCP LEG for more
information.
Step 3 Load the configuration files to the SM using the p3sm CLU
Run the p3sm command line utility from the SM CLU.
>p3sm --load-config
Step 4 Configure the SCE to send RDRs to the LEG
Run the RDR-formatter CLI on the SCE platform to add the LEG as a category 3 RDR destination. You
must use the same port number as defined by the RDR server in the SM. The default port number is
33001.
Note To support SM cluster topology, set the cluster VIP as the SM-IP in the following CLI.
SCE2000>configure
SCE2000(config)>RDR-formatter destination SM-IP port port category number 3 priority 100
SCE2000(config)>exit
Uninstalling the SCE-Sniffer DHCP LEG
Step 1 Remove the configuration of the RDR-formatter.

Run the RDR-formatter CLI on the SCE platform to remove the LEG as a category 3 RDR destination:
SCE2000>configure
SCE2000(config)>no RDR-formatter destination SM-IP port port
Step 2 Uninstall the SCE-Sniffer DHCP LEG by running the p3inst CLU
>p3inst --uninstall -f dhcpsnif.pqi
Note After the uninstall process, the SM restarts automatically.
Upgrading the SCE-Sniffer DHCP LEG

The SCE-Sniffer DHCP LEG and SM versions must be identical; therefore, the SCE-Sniffer DHCP LEG
must be upgraded as part of the SM upgrade process. The upgrade for the SCE-Sniffer DHCP LEG
should be performed together with the upgrade process of the SM.
Step 1 Backup the configuration files of the SCE-Sniffer DHCP LEG.

14-2 OL-15752-01
Step 2 Force the SCEs to store the RDRs during the upgrade.
To force the SCEs to store the RDRs, disable the RDR Server on the SM by setting the start parameter
in the RDR Server section to false and loading the configuration by running the following CLU:
>p3sm --load-config
Step 3 Uninstall the SCE-Sniffer DHCP LEG by running the p3inst CLU
>p3inst --uninstall -f dhcpsnif.pqi
Note After the uninstall process has successfully completed, the SM automatically restarts.
Step 4 Perform an upgrade of the SM

The SM upgrade procedure is described in the Cisco SCMS Subscriber Manager User Guide.
Step 5 Install the new version of the SCE-Sniffer DHCP LEG by running the p3inst CLU
>p3inst --install -f dhcpsnif.pqi
Step 6 Restore the configuration files of the SCE-Sniffer DHCP LEG.
Step 7 To make the SCEs send the RDRs that they stored during the upgrade, enable the RDR Server on the SM
by setting the start parameter in the RDR Server section to true.
Step 8 Load the new configuration of the SM by running the p3sm CLU
>p3sm --load-config

OL-15752-01 14-3

14-4 OL-15752-01
CH A P T E R 15
Configuring the SCE-Sniffer DHCP LEG
This module describes how to configure the SCE-Sniffer DHCP LEG.
Information About Configuring the SCE-Sniffer DHCP LEG

The SCE-Sniffer DHCP LEG is configured using two configuration files, dhcpsnif.cfg and
dhcp_pkg.cfg, which reside in the sm-inst-dir /sm/server/root/config directory (sm-inst-dir refers to the
SM installation directory).
The configuration files consist of sections headed by a bracketed section title; for example, [RDR
Server]. Each section consists of several parameters having the format parameter=value. The number
sign (“#”) at the beginning of a line signifies that it is a remark line.
The general configuration of the SCE-Sniffer DHCP LEG resides in dhcpsnif.cfg. The dynamic package
association configuration resides in dhcp_pkg.cfg.
• Configuring the General Settings, page 15-1
• Configuring Policy Association, page 15-3
Configuring the General Settings

The following is a description of the configuration variables of dhcpsnif.cfg.
The [SCE-Sniffer DHCP LEG] section contains the following parameters:
• start
Defines whether the SM runs the SCE-Sniffer DHCP LEG at startup.
To extract and handle the DHCP messages received by the RDR server, this parameter must be set
to yes .
• log_failures
Defines whether the SM should add messages about failures to the user log.
• log_all
Defines whether the SM should add all messages, including successful logins and logouts, to the
user log.

OL-15752-01 15-1
Chapter 15 Configuring the SCE-Sniffer DHCP LEG
• use_default_domain
Defines whether all login operations should use the default domain “subscribers”.
If the value is set to false, the SM will log in the subscribers using the domain name identical to the
IP address of the SCE that received the DHCP traffic for that subscriber. In this case, you will have
to configure domain aliases as described in Cisco SCMS Subscriber Manager User Guide.
• is_cable
Indicates whether to check if this is a cable modem transaction; i.e., compare the value of the
Remote-Id sub-option (option 82 sub-option 2) with the haddr DHCP header field. If it is a cable
modem transaction, use only the policy information.
The [Sniffer] section contains the following parameters:
• packet_types
Contains the DHCP packet types to send to the LEG.
Possible values for this parameter are any combination of the following types: DHCPACK,
DHCPRELEASE. The default value is set to DHCPACK and DHCPRELEASE.
Note For this LEG to work correctly, use the configuration file to enable the RDR server in the SM.
The [Subscriber ID] section contains the following parameters:

• dhcp_option
Defines which DHCP option to use for subscriber ID association. For DHCP options that have sub
options, a colon separates the DHCP option and the sub option. The default value is
Relay-Agent-Information using the Remote-Id information, i.e. 82:2.
• dhcp_option_type
Defines the format type of the DHCP option defined by the dhcp_option parameter above.
Possible values for this parameter are binary or string. The default value is binary.
• default_id
Defines the type of fallback that occurs when packet does not contain the configured DHCP option.
The possible value for this parameter is ip for using the allocated IP to create a subscriber ID in the
format IP_a.b.c.d. If this parameter is not set, no fallback occurs, and the login fails. The default is
not set.
The following is an example of a configuration file:
[SCE-Sniffer DHCP LEG]
start=yes
log_failures=true
log_all=false
use_default_domain=true
is_cable=true
[Sniffer]
packet_types=DHCPACK
[Subscriber ID]

15-2 OL-15752-01
dhcp_option=82:2
dhcp_option_type=binary
default_id=ip
Configuring Policy Association
Subscriber policy configuration in the SCE-Sniffer DHCP LEG can be handled in any of the following
ways:
• Dynamic assignment of policy information using information extracted from the DHCP packet, See
Dynamic Assignment of Policy Information, page 15-3.
• Static assignment of a constant package Id for all subscribers that log on via the SCE-Sniffer DHCP
LEG, See Static Assignment of Policy Information, page 15-6.
Dynamic Assignment of Policy Information

Dynamic assignment of policy information is supported if the policy information is submitted in the
DHCP packets. The LEG concatenates the desired options and creates a policy-name. It is possible to
map, using the configuration, between the policy-names and the application policy parameters such as
package IDs and Virtual-links. The SCE-Sniffer DHCP LEG can support multiple policies.
To extract the policy information data from the DHCP packet, use the dhcp_pkg.cfg configuration file
to define the option types that contain the policy information and define the conversion map of the
policy-names to the package IDs (or any other policy) of the Service Control Application for Broadband
(SCA BB).
The LEG is able to add additional data to the login operation based on the LEG configuration. This data
is added as a key-value pair. Other modules in the login chain can use this data, such as the SOAP LEG
(see the SOAP LEG section). This data can be created by concatenating the data of several DHCP options
and can be given a user-defined label.
The [DHCP.Policy.XXX] sections contain the following parameters:
• options_order_for_policy_name
Defines the DHCP options that contain the policy association information and defines the order of
concatenation of the data. The DHCP header field called giaddr (Relay-Agent IP) is also supported;
it requires the use of the type integer in the option_type parameter.
The format is: option[:subtype],option[:subtype],giaddr
• options_type
Defines the format type of the DHCP options and fields defined by the
options_order_for_policy_name parameter.
hexadecimal string), string (an ASCII string), or integer (a 4-byte integer converted to an IP
address string in dotted notation). Order the list in the same way as
options_order_for_policy_name.

OL-15752-01 15-3
Defines the separator character to use between two options when concatenating them to each other
to create the policy name. Any character is accepted. The default value is '_'.
• use_default
Determines whether to use a default policy when no policy information can be extracted from the
DHCP data, such as the configurable options are missing or no options were configured.
• default_policy
Defines the default policy ID to use if no policy information is extracted from the DHCP data. This
parameter is relevant only if the use_default parameter is set to true.
Possible values for this parameter are any integer number. This parameter has no default value.
Defines whether to perform a login without policy information when no policy information can be
extracted from the DHCP data and the use_default parameter is set to false.
This parameter is relevant only if the use_default parameter is set to false.
Defines the name of the application property that contains the policy information. This parameter
has no default value.
SCA BB Console. For example, packageId, monitor, upVlinkId, or downVlinkId.
• log_all
• log_default_assignment
by the default_policy parameter).
• mapping_table.<policy_name>
Multiple entries containing the information to convert from the policy information as it appears in
the DHCP packet to the policy property value to be used by the SCA BB application.
These entries do not have default values.
Note The policy_name is case sensitive and must be written exactly as it exists in the DHCP packets.
The [Additional Data] section of the configuration file contains the following parameters:
• label_options
Defines which DHCP option to extract to add to the login operation.

15-4 OL-15752-01
Possible values are the option number or, in the case of DHCP options with sub-options, the option
and sub-option separated by a colon. For example, 43:123 or 61.
• label_keys
Defines the keys that should mark the DHCP options defined by the label_options parameter.
• label_options_type
Defines the format type of the DHCP option defined by the label_options parameter.
hexadecimal string) or string (an ASCII string).
The default value is binary.
Dynamic Assignment of Policy Information Example

Suppose that the policy information appears inside option 43 (Vendor Specific Option) of the DHCP
packet and that both subtypes, 102 and 101, are in use. Configure the options_order_for_policy_name
parameter as follows:
Suppose that option 43 with subtype 102 contains the type of package (gold, silver, or bronze), and that
option 43 with subtype 101 contains domain information (the package type has a different meaning in
different domains). If the separator value is configured to the default value, configure the mapping_table
entries as follows:
This configuration means that if the DHCP packet contains the value 'gold' inside option 43 with subtype
102, and the value 'domain1' inside option 43 with subtype 101, the package ID that will be associated
to the subscriber in the SM will have the value 11.
The following configuration describes how to add the data of the Relay-Agent Circuit-Id option as
additional data to the login operation:
[Additional Data]
label_options=82:1
label_keys=PORT_ID
label_option_type=string
name_separator_value=_
use_default=true
default_policy=1
log_all=false
log_default_assignment=false
[Additional Data]

OL-15752-01 15-5
label_options=82:1
label_keys=PORT_ID
label_option_type=string
Static Assignment of Policy Information

If the installation does not require dynamic assignment of package information, the configuration file
dhcp_pkg.cfg should define the default package ID to be assigned to all the subscribers, as shown in the
following example:
use_default=true
default_policy=1
[DHCP.Policy.VirtualLinkDownstream]
policy_property_name=downVlinkId
use_default=true
default_policy=0
[DHCP.Policy.VirtualLinkUpstream]
policy_property_name=upVlinkId
use_default=true
default_policy=0
All other configuration parameters should not be set.

15-6 OL-15752-01
CH A P T E R 16
Using the SCE-Sniffer DHCP LEG CLU
This module describes the SCE-Sniffer DHCP LEG command-line utility (CLU).
Information About the SCE-Sniffer DHCP LEG CLU

The p3dhcpsniff utility displays the SCE-Sniffer DHCP LEG configuration, status, and statistics. The
command format is p3dhcpsniff <operation>.
The following table lists the p3dhcpsniff operations.
Table 16-1 p3dhcpsniff Operations
--show Displays all of SCE-Sniffer DHCP LEG
configurations and status
--show-statistics Displays counters of DHCP messages handled and
number of logon operations performed
--show-version Displays the version information of the
SCE-Sniffer DHCP LEG
arguments, with a short explanation of their
meanings.
• Viewing the SCE-Sniffer DHCP LEG Status, page 16-1

• Viewing the SCE-Sniffer DHCP LEG Statistics, page 16-2
• Viewing the SCE-Sniffer DHCP LEG Version, page 16-2
Viewing the SCE-Sniffer DHCP LEG Status

The following is an example using the p3dhcpsniff CLU with the show operation:
>p3dhcpsniff --show
SCE-Sniffer DHCP LEG:
=====================
Active: true
DHCP message types:
DHCPACK

OL-15752-01 16-1
Chapter 16 Using the SCE-Sniffer DHCP LEG CLU
Information About the SCE-Sniffer DHCP LEG CLU
DHCPRELEASE
DHCP options with package information:
type = 43, subtype = 102
type = 43, subtype = 101
Subscriber ID:
Option: 82:2
Format: binary
Fallback: none
>
Viewing the SCE-Sniffer DHCP LEG Statistics

The following is an example of using the p3dhcpsniff CLU with the show-statistics operation:
>p3dhcpsniff --show-statistics
SCE-Sniffer DHCP LEG statistics
===============================
Received DHCP RDRs: 12
RDRS for DHCP initial login or lease renewal: 12
RDRs for DHCP release: 0
Invalid DHCP RDRs: 0
Number of DHCP RDRs without subscriber Id: 0
Failed logins: 0
Failed logouts: 0
>
Viewing the SCE-Sniffer DHCP LEG Version

The following is an example of using the p3dhcpsniff CLU with the show-version operation:
>p3dhcpsniff --show-version
SCE-Sniffer DHCP LEG 3.1.0 Build 176
>

16-2 OL-15752-01
P A R T 4
RADIUS Listener LEG

CH A P T E R 17
About the RADIUS Listener LEG
This module describes the Service Control Management Suite (SCMS) Subscriber Manager (SM)
RADIUS Listener Login Event Generator (LEG) software module.
• About the RADIUS Listener LEG, page 17-1
• Topologies, page 17-2
About the RADIUS Listener LEG

The RADIUS Listener LEG is a software module that receives RADIUS Accounting messages, and
according to their content, invokes logon operations to the Subscriber Manager (SM). It also provides
dynamic integration for subscribers over VPN. The RADIUS Listener LEG is an extension to the SM
software and runs concurrently with the SM.
When the RADIUS Listener LEG receives an Accounting-Start message, it extracts the subscriber ID,
the subscriber IP-address, the VLAN-ID, and optionally, the subscriber package index from the message
attributes, and triggers a login operation to the SM. In the same manner, Accounting-Interim-Update
triggers a login operation, and the Accounting-Stop message triggers a logout operation.
The RADIUS Listener LEG also contains a regular expression utility. This command-line utility (CLU)
can be used to test regular expression “spelling” validity, test and show the reduction and
pattern-matching of an input list of strings against certain regular-expression patterns, and provide the
user with detailed output for each manipulation operation result.
The RADIUS Listener LEG was carefully developed and thoroughly tested with several RADIUS AAA
servers and NAS devices.

OL-15752-01 17-1
Chapter 17 About the RADIUS Listener LEG
Topologies
Topologies
The following diagram illustrates a topology in which a RADIUS server/proxy forwards or proxies the
RADIUS Accounting messages to the RADIUS Listener LEG.
Figure 17-1 Example of RADIUS Server Forwarding RADIUS Accounting Messages to RADIUS
Listener LEG
RADIUS RADIUS
Server/Proxy Listener
Control
Links
NAS / GGSN
SCE
Edge Router
Internet
NAS / GGSN Traffic SCE
157112
Links
The following diagram illustrates a topology in which the NAS performs authentication with the
RADIUS server, and sends RADIUS Accounting messages to the RADIUS Listener LEG and,
optionally, to the RADIUS server.
Figure 17-2 Example of NAS Sending RADIUS Accounting Messages to both the RADIUS Listener
LEG and the RADIUS Server
RADIUS RADIUS
Control RADIUS
Links Accounting
NAS / GGSN
SCE
Edge Router
Internet
NAS / GGSN Traffic SCE
157113
Links

17-2 OL-15752-01
CH A P T E R 18
Installing the RADIUS Listener LEG
This module describes the procedures for installing the software on the subscriber manager (SM). It also
describes uninstalling the software.
The RADIUS Listener LEG is part of the SM installation package. The installation package also includes
configuration files and the Command-Line Utility of the LEG.
• Installing the RADIUS Listener LEG Software, page 18-1
• Uninstalling the RADIUS Listener LEG, page 18-2
Installing the RADIUS Listener LEG Software

Step 1 Edit the RADUIS Listener LEG configuration file.
To run the RADIUS Listener LEG at SM startup, set the start parameter to yes. See Configuring the
General Settings, page 19-1.
Step 2 Load the configuration file using the p3sm command-line utility.
Run the p3sm command-line utility from the SM CLU sm-inst-dir/sm/server/bin (sm-inst-dir refers
to the SM installation directory):
>p3sm --load-config
Step 3 Configure the NAS devices that are sending RADIUS Accounting messages to the RADIUS Listener
LEG.
The NAS devices may be RADIUS servers acting as RADIUS clients that proxy or forward RADIUS
accounting messages to the RADIUS Listener.
These RADIUS clients must be configured according to the RADIUS Listener configuration, as
performed in Step 1 above. There are many different RADIUS client devices, each of which is
configured in a different manner. See Configuring the NAS Devices for instructions on configuring the
RADIUS clients on NAS devices.

OL-15752-01 18-1
Chapter 18 Installing the RADIUS Listener LEG
Uninstalling the RADIUS Listener LEG
Uninstalling the RADIUS Listener LEG

Step 1 Edit the SM configuration file and set the RADIUS Listener start parameter to no.
For further information, see Configuring the General Settings, page 19-1.
Note Setting the start parameter to no does not remove the RADIUS Listener LEG from the SM installation.
You can reinstall the software again by setting the start parameter to yes.
Step 2 Run the p3sm CLU.

>p3sm --load-config

18-2 OL-15752-01
CH A P T E R 19
Configuring the RADIUS Listener LEG
This module describes the configuration procedure for the RADIUS Listener LEG.
The RADIUS Listener LEG is configured using the SM configuration file p3sm.cfg, which resides in
the sm-inst-dir/sm/server/root/config directory (sm-inst-dir refers to the SM installation directory).
The configuration file consists of sections headed by a bracketed section title; for example,
[Radius.Subscriber ID]. Each section consists of several parameters having the format
parameter=value. The number sign (“#”) at the beginning of a line signifies that it is a remark.
The general RADIUS Listener LEG configuration settings reside in the [Radius Listener] section. All
additional RADIUS Listener LEG sections start with the prefix Radius., such as [Radius.NAS.nas1],
and they are defined initially as remark lines.
• Information About the Regular Expression Utility, page 19-2
• Configuring RADIUS Attributes Mapping, page 19-6
• Configuring the NAS Devices, page 19-13
[Radius Listener] Section

The [Radius Listener] section in the SM configuration file contains the following parameters:
• start
Defines whether the SM should run the RADIUS Listener at startup.
• accounting_port
Defines the RADIUS Listener accounting port number.
The default value is 1813.

OL-15752-01 19-1
Chapter 19 Configuring the RADIUS Listener LEG
Information About the Regular Expression Utility
• ip
The IP address to which the RADIUS listener should bind. Use this parameter only in cases where
the IP address used for RADIUS transactions is not the main IP address of the SM machine. (For
example in an SM cluster.)
Possible values are any IP address in dotted notation. The default value is not set.
• packet_types
Defines the RADIUS protocol packet types to analyze.
Possible values are accounting-start, accounting-interim, accounting-stop separated by a
comma.
The default value is accounting-start,accounting-interim,accounting-stop.
Example
The following example is a portion of a configuration file illustrating the [Radius Listener] section:
[Radius Listener]
# The following parameter defines whether the SM should
# run the RADIUS Listener at startup.
# Receives the values: yes, no. (default no)
start=no
# accounting port number (default 1813)
accounting_port=1813
# RADIUS packet types
packet_types=accounting-start,account-interim,accounting-stop

A regular expression consists of a character string where some characters are given special meaning with
regard to pattern matching. Regular expressions have been in use from the early days of computing, and
provide a powerful and efficient way to parse, interpret and search and replace text within an application.
• Supported Syntax, page 19-2
• Unsupported Syntax, page 19-4
• Regular Expression Examples, page 19-4
• Regular Expression Processing versus RADIUS Listener Login Rate, page 19-5
Supported Syntax
Within a regular expression, the following characters have special meaning:
• Positional Operators
– ^ matches at the beginning of a line
– $ matches at the end of a line
– \A matches the start of the entire string
– \Z matches the end of the entire string
– \b matches at a word break (Perl5 syntax only)

19-2 OL-15752-01
– \B matches at a non-word break (opposite of \b) (Perl5 syntax only)

– \<matches at the start of a word (egrep syntax only)
– \>matches at the end of a word (egrep syntax only)
• One-Character Operators
– . matches any single character
– \d matches any decimal digit
– \D matches any non-digit
– \n matches a newline character
– \r matches a return character
– \s matches any whitespace character
– \S matches any non-whitespace character
– \t matches a horizontal tab character
– \w matches any word (alphanumeric) character
– \W matches any non-word (alphanumeric) character
– \x matches the character x, if x is not one of the above listed escape sequences
• Character Class Operator
– [abc] matches any character in the set a, b, or c
– [âbc] matches any character not in the set a, b, or c
– [a-z] matches any character in the range a to z, inclusive
– A leading or trailing dash will be interpreted literally.
• Within a character class expression, the following sequences have special meaning if the syntax bit
RE_CHAR_CLASSES is on:
– [:alnum:] Any alphanumeric character
– [:alpha:] Any alphabetical character
– [:blank:] A space or horizontal tab
– [:cntrl:] A control character
– [:digit:] A decimal digit
– [:graph:] A non-space, non-control character
– [:lower:] A lowercase letter
– [:print:] Same as graph, but also space and tab
– [:punct:] A punctuation character
– [:space:] Any whitespace character, including newline and return
– [:upper:] An uppercase letter
– [:xdigit:] A valid hexadecimal digit
• Subexpressions and Backreferences
– (abc) matches whatever the expression abc would match, and saves it as a subexpression. Also
used for grouping.
– (?:...) pure grouping operator, does not save contents

OL-15752-01 19-3
– (?#...) embedded comment, ignored by engine

– \n where 0 < n <10, matches the same thing the nth subexpression matched.
• Branching (Alternation) Operator
– a|b matches whatever the expression a would match, or whatever the expression b would match.
• Repeating Operators
These symbols operate on the previous atomic expression.
– ? matches the preceding expression or the null string
– * matches the null string or any number of repetitions of the preceding expression
– + matches one or more repetitions of the preceding expression
– {m} matches exactly m repetitions of the one-character expression
– {m,n} matches between m and n repetitions of the preceding expression, inclusive
– {m,} matches m or more repetitions of the preceding expression
• Stingy (Minimal) Matching
If a repeating operator is immediately followed by a ?, the repeating operator will stop at the
smallest number of repetitions that can complete the rest of the match.
• Lookahead
Lookahead refers to the ability to match part of an expression without consuming any of the input
text. There are two variations to this:
– (?=foo) matches at any position where foo would match, but does not consume any characters
of the input.
– (?!foo) matches at any position where foo would not match, but does not consume any
characters of the input.
Unsupported Syntax
Some flavors of regular expression utilities support additional escape sequences, and this is not meant
to be an exhaustive list of unsupported syntax.
• (?mods) inlined compilation/execution modifiers (Perl5)
• \G end of previous match (Perl5)
• [.symbol.] collating symbol in class expression (POSIX)
• [=class=] equivalence class in class expression (POSIX)
• s/foo/bar/ style expressions as in sed and awk (note: these can be accomplished through other means
in the API)
Regular Expression Examples

The following examples show how to perform some basic manipulation using the regular expression
tool.
• In order to remove the “cisco.com” suffix from a given name (e.g. name@cisco.com), define the
following manipulation rule: (.*)@.*

19-4 OL-15752-01
• In order to remove the “name” prefix from a given name (e.g. name@cisco.com), define the
following manipulation rule: .*@(.*)
• If no reduction is needed, either define the following reduction rule (.*) , or do not define any rule.
• In order to find a partial match from of a name (e.g. find 'isco' in name@cisco.com), define the
following matching rule: mapping_table.cisco=<value>
• In order to find a full match of a name, define the following matching rule:
mapping_table.cisco=<value>
• In order to define a default value for an empty or non-existent attribute value:
mapping_table.^$=<value>
Note If the character or string was not found in the input string when performing reduction (stripping
characters or strings), the result of the regular expression is an empty string. In previous versions, if the
character or string was not found in the input string when performing reduction, the result of the regular
expression is the input string.
Note Brackets '[' or ']' are used by the regular expression mechanism and also in the section definitions in the
configuration files. If either of these characters form a part of the reduction rule definition
(field_manipulation parameter) or in matching rule definition (mapping_table parameter), it should be
preceded by two backslashes ('\\') in order to be used as part of the value.
Note For example:
[Sample Section]
mapping_table.^12\\[user7$=7 will have a full match result to the '12\[user7' string
mapping_table.^12\[user7$=7 will have a full match result to the '12[user7' string
mapping_table.^12[user7$=7 will have a full match result to the '12[user7' string as well.
Note Parentheses '(' or ')' and the pipe character '|' should be preceded by a single backslash '\'. For example,
if you have the rule ^(?:88|99)(.*)$ --input=886, the CLU command should be as shown in the
following example:
p3radius --test-reduction-rule --reg-exp=^$?:88\|99$$.*$$ --input=886
Regular Expression Processing versus RADIUS Listener Login Rate

Using regular expressions for string reduction and/or pattern matching can cause performance
degradation on the RADIUS listener login rate. When using regular expressions, it is important to define
the correct reduction and match patterns.
There are three elements that affect the regular expression processing time.
• The complexity of the pattern.
• The length of the input string to reduce or match; a longer string will cause longer regular expression
operation.
• The total number of reduction and matching rules defined in the configuration file.

OL-15752-01 19-5
Configuring RADIUS Attributes Mapping
The following examples demonstrate regular expression operations that do not significantly impact
performance:
• Removal of prefixes or suffixes—Use a regular expression of the format .*<String>(.*) or
(.*)<String>.*.
• Matching prefixes or suffixes—Use a regular expression of the format ^<String>or <String>$.
To calculate the impact of the regular expression usage on the login rate, the p3radius
test-reduction-rule and test-manipulation-rule CLU commands provide the average processing time
for a single reduction/matching operation.
Note Using complex regular expression patterns will cause performance degradation; the degradation
increases relative to the length of the string being manipulated. It is strongly recommended not to use
the [] operands with the .* or with the (.*) operands.

• Mapping of RADIUS Attribute to Subscriber ID, page 19-6
• Mapping of RADIUS Attribute to Subscriber Policy, page 19-9
• Mapping of RADIUS Attribute to Subscriber IP Address, page 19-11
Mapping of RADIUS Attribute to Subscriber ID
The subscriber ID is usually put in the User-Name RADIUS attribute. However, in certain installations,
it is possible to use a different RADIUS attribute. For example, in wireless environments, it is possible
to use the 3GPP-IMSI or the 3GPP2-IMSI attributes. The default is to use the User-Name attribute.
The RADIUS Listener can be configured to concatenate several RADIUS attributes for use as the
Subscriber ID.
To define which attribute(s) to use for the subscriber ID, configure the [Radius.Subscriber ID] and the
[Radius.Field.<field name>] sections. To define the attribute(s) to use, configure the following
parameters in the [Radius.Subscriber ID] section:
• fields
Defines the RADIUS protocol fields names. When defining multiple fields, use commas between
the field names. The field name must not start or end with a space character and it cannot contain
an '=' character. A maximum of three fields can be defined.
The default value is user_name.
The following is an example of setting this parameter:
fields=user_name,vpn

19-6 OL-15752-01
• field_separator
Defines the character or string to be used when concatenating several fields.
In you define three values for the fields parameter (user_name, vpn, and IP) and the field separator
is being defined:
– The field_separator parameter must contain user_name, vpn, and IP in the same order as they
were defined in the fields parameter.
– The separator character between the 1st and 2nd attributes and between the 2nd and 3rd
attributes can be different; for example, user_name-vpn::IP
– The separator can be string; for example, ::
– The separator can be an empty string; for example, field_separator=user_namevpnIP
• The default value is _.
The following is an example of setting this parameter with the value '-':
field_separator=user_name-vpn
• field_manipulation.<field name>=<regular expression>
The field_manipulation parameters define how to manipulate the RADIUS field values.
The <field name> part of this parameter is one of the fields defined in the fields parameter. The
<regular expression> part of this parameter is the reduction regular expression to be used on the
<field name> value.
It is possible to define a field_manipulation rule for each name in the field property. The following
is an example of setting this parameter:
field_manipulation.user_name=(.*)@.*
field_manipulation.vpn=(.*)
It is possible to configure the RADIUS listener to strip a RADIUS attribute based on a selected
character or string using a regular expression rule. This provides a convenient method for obtaining
the subscriber ID from a prefix or a suffix of an attribute value.
For example, you can obtain the subscriber ID from the USERNAME attribute value of
subscriber@domain-name by stripping the characters from the value by using the (.*)@.* regular
expression rule to produce the subscriber. Similarly, you can obtain the domain name by using the
.*@(.*) regular expression rule.
For each field defined by the fields parameter, you must also define a [Radius.Field.<field name>]
section with the following parameters:
• radius_attribute
Configure the radius_attribute parameter with the RADIUS attribute number. Use the following
format for Vendor Specific Attributes (VSA): 26(vendor-id;sub-attribute). For example,
26(10415;1).
The default value is -1.
• radius_attribute_type
Configure radius_attribute_type parameter according to the RADIUS attribute format.
Possible values for this parameter are integer and string. The default value is string.

OL-15752-01 19-7
Validation Rules
When regular expression rules are used for reduction of RADIUS attributes, the following validation
rules are applied:
• The protocol field amount must not exceed three fields.
• Each field defined in the fields parameter must have a corresponding [Radius.Field.<field>] section.
• If the separator character is defined, the order of the fields is checked.
• Each field defined in the fields parameter may have a single reduction regular expression rule. If a
rule exists, the regular expression validity check is performed.
Configuring the Subscriber ID Example

The following is an example configuration file illustrating how to configure the subscriber ID
assignment option. In this example, the User-Name and VPN attributes are assigned to the subscriber ID:
[Radius.Subscriber ID]
# Field name
# Field separator
# "-" is the separator between the user_name and vpn fields.
field_separator=user_name-vpn
[Radius.Field.user_name]
# RADIUS protocol attribute number
radius_attribute=1
# the type of the attribute (type "integer" or "string")
radius_attribute_type = string
[Radius.Field.vpn]
# RADIUS protocol attribute number .
radius_attribute = 5
radius_attribute_type = integer
Configuring the Vendor Specific Attribute (VSA) as Subscriber ID Example

The following is an example configuration file illustrating how to configure the subscriber ID
assignment option. In this example, the 3GPP_IMSI vendor-specific attribute is assigned to the
subscriber ID:
# Field name
fields=user_name
# in case of a vendor specific attribute (VSA)
# when the 'radius_attribute' is set to 26
# configuration for 3GPP_IMSI
radius_attribute = 26(10415;1)
Configuring Stripping of the Attribute Value Example using Regular Expression Rule
The following is an example configuration file illustrating how to configure the stripping of an attribute
value using a regular expression rule:

19-8 OL-15752-01
# Field name
fields=user_name
# Field manipulation
radius_attribute=1
The above configuration applied on ‘john@some-domain.com’ will extract “john” as a Subscriber ID.
Mapping of RADIUS Attribute to Subscriber Policy
Subscriber policy configuration in the RADIUS Listener can be handled in any of the following ways:
• Extract the data from a RADIUS attribute
• Set a default value for all subscribers that log on via the RADIUS Listener
• Do not set any policy to the subscriber
Extracting Data from a RADIUS Attribute

To define which RADIUS attribute to use for the subscriber policy, configure the
[Radius.Property.Package] and [Radius.Field.<field name>] sections. To define the attribute to be
used, configure the following parameters:
• fields
Defines the RADIUS protocol fields names. When defining multiple fields, use commas between
the field names. The field name must not start or end with a space character and it cannot contain
an '=' character.
The following is an example of setting this parameter:
fields=user_name,ip
• field_separator
Defines the character to be used when concatenating several fields.
The default value is _.
The following is an example of setting this parameter with the value '-':
field_separator=user_name-ip
• field_manipulation.<field name>=<regular expression>
The field_manipulation parameters define how to manipulate the RADIUS field values.
The <field name> part of this parameter is one of the fields defined in the fields parameter. The
<regular expression> part of this parameter is the reduction regular expression to be used on the
<field name> value.

OL-15752-01 19-9
It is possible to define a field_manipulation rule for each name in the field property. This is the
default rule if there is a non-configured field manipulation. The following is an example of setting
this parameter:
field_manipulation.ip=(.*)
• mapping_table.<regExp>=<property-value>
The mapping_table parameters define a conversion table between the result of the attribute value
manipulation, the matching rule, and the property value.
The <regExp>part of this parameter defines the regular expression matching rule. The
<property-value>part of this parameter defines the integer result if the regular expression is
matched.
There is no default value for this parameter, but it is possible to set a default value by using the
following expression: mapping_table.^$=<value>. This value is used if the mapping result is an
empty string.
The following is an example of setting this parameter.
mapping_table..*@.*=1
mapping_table..*=2
For each field defined by the fields parameter, you must also define a [Radius.Field.<field name>]
26(10415;1).
Validation Rules
When regular expression rules are used for reduction of RADIUS attributes, the following validation
rules are applied:
• The protocol field amount must not exceed three fields.
• Each field defined in the fields parameter must have a corresponding [Radius.Field.<field>] section.
• The property value in the mapping table is an integer.
• The “=” operator is concatenated to the property value with no space between them.
• A validity test is performed for each regular expression that is used for matching and reduction.
Extracting Data from a RADIUS Attribute Example

The following example is a portion of a configuration file illustrating how to configure the subscriber
policy assignment option. In this example, a VSA is assigned to the subscriber policy. It is stripped from
its prefix and converted to integer type using a mapping table.
[Radius.Property.Package]
# Field name

19-10 OL-15752-01
# Field separator
field_separator=user_name@vpn
# Field manipulation
# Mapping table
mapping_table..*@.*=1
mapping_table.^$=2
mapping_table..*=3
radius_attribute type = string
[Radius.Field.vpn]
# RADIUS protocol attribute number.
# use the following format for VSAs: 26 vendor-id;sub-attribute)
# for example: 26(9;1)
Not Setting Any Policy to the Subscriber

Edit the [Radius.Property.Package] section with all remark lines. The number sign ("#") at the
beginning of a line signifies a remark line.
Mapping of RADIUS Attribute to Subscriber IP Address

The subscriber IP address is normally based on the Framed-IP-Address attribute; however, it can also be
based on a different RADIUS attribute. The default is to use the Framed-IP-Address attribute.
In addition, for environments with IP addresses over VPN, the RADIUS Listener LEG supports the
extraction of VPN information from a RADIUS attribute to be used with the extracted IP address.
Note Currently the LEG supports subscriber mappings over VPN only for VPNs that are defined by a
VLAN-ID (also referred to as "VPNs of type VLAN").
The following algorithm is applied to handle IP addresses in this LEG:

1. If the user configured an attribute from which to extract the IP, the LEG will look for that attribute
in the packet. If the attribute exists, the LEG will use the attribute as the subscriber IP address.
2. If the attribute does not exist or is not configured, the LEG will look for the Framed-Route
attributes; several Framed-Route attributes may exist. If any Framed-Route attributes exist, the LEG
will use these attributes as the subscriber IP addresses.
3. If there are no Framed-Route attributes, the LEG will look for a Framed-IP-Address attribute and a
Framed-IP-Netmask attribute. If a Framed-IP-Address attribute exists, the LEG will use this
attribute as the subscriber IP address. If both the Framed-IP-Address and the Framed-IP-Netmask
attributes exist, the operation is performed with the IP range represented by the IP address and the
IP netmask.
4. Otherwise, the LEG will perform a login without the IP address.

OL-15752-01 19-11
Note The configured attribute can be a regular RADIUS attribute or a VSA. It is possible to encode the
attribute as an integer in which case it will be a single IP address. It can also be encoded as a string and
will therefore be an IP-Address/IP-Range value: the value must be formatted as A.B.C.D/E or A.B.C.D.
Note The supported format of the Framed-Route attribute is as described in RFC-2865. It must start with a
string that starts with the route itself in the format A.B.C.D/E followed by a space. Other values follow
the space, but the LEG ignores these other values.
To define which attribute to use for the subscriber IP address, configure the [Radius.Subscriber IP
Address] and the [Radius.Field.<field name>] section. To define the attribute to use, configure the
following parameters:
• fields
Defines the RADIUS protocol field name. Only one field name can be defined.
The default value is not set.
• vpn_field
Defines the RADIUS protocol attribute field name to be used as the VPN information related to the
IP address.
The default value is not set.
For the field defined by the fields parameter, you must also define a [Radius.Field.<field name>]
26(10415;1).
Configuring Subscriber IP Address Example

The following is an example configuration file illustrating how to configure the subscriber IP assignment
option. In the following example, the Framed-IP-Address attribute is used.
[Radius.Subscriber IP Address]
# Field name for IP
fields=frame-ip-address
[Radius.Field.frame-ip-address]
radius_attribute=8
# if type is string a mapping table must be supplied
# below.
# (no default)
radius_attribute_type=integer

19-12 OL-15752-01
Configuring the NAS Devices
Configuring Subscriber IP Address over VPN Example

The following is an example configuration file illustrating how to configure the subscriber IP assignment
option for IP over VPN. In the following example, the Framed-IP-Address attribute is used for the IP
address and the cisco-av-pair VSA attribute is used for the VPN information.
[Radius.Subscriber IP Address]
# RADIUS protocol field name.
fields=ip
# RADIUS protocol attribute field name to be used as the
# VPN information related to the IP address.
vpn_field=vpn
[Radius.Field.ip]
radius_attribute type = integer
[Radius.Field.vpn]
# RADIUS protocol attribute number.
# use the following format for VSAs: 26 vendor-id;sub-attribute)
# for example: 26(9;1)
radius_attribute_type = integer

The RADIUS Listener LEG must be configured with the RADIUS clients/NAS devices that transmit
RADIUS messages to the LEG, to accept RADIUS messages.
Each [Radius.NAS.XXX] section specifies a single Network Access System (NAS), where XXX
represents the NAS name.
Step 1 Copy the example Radius.NAS.XXX section that exists in the configuration file
The remarks from the parameters and section header should be removed.
Step 2 Configure a section name of the format [Radius.NAS.my_name_for_the_NAS].
Step 3 Configure the domain, IP_address, NAS_identifier, and secret parameters:
• domain
Set the domain parameter with a valid subscriber domain name.
• IP_address
Set the IP_address parameter with the NAS IP address with which the RADIUS messages arrive. IP
address should be in dotted notation (xxx.xxx.xxx.xxx).
• NAS_identifier
Set the NAS_identifier parameter with a NAS-ID attribute with which the RADIUS messages are
sent.
• secret
Set the secret parameter with the secret key defined in the NAS for this connection.

OL-15752-01 19-13
Configuring the NAS Devices: Example

This example is a portion of a configuration file illustrating how to configure the NAS:
[Radius.NAS.Access134]
# Cisco's subscriber domain name
domain = subscribers
# IP address in dotted notation
IP_address = 202.156.24.100
# name of the NAS that exists in the NAS-ID attribute
NAS_identifier =ACCESS134
# secret string
secret = secret123

19-14 OL-15752-01
CH A P T E R 20
Configuring the RADIUS Client
This module describes the configuration procedure for a RADIUS Client.

The RADIUS clients are needed to send RADIUS messages to the RADIUS Listener and must be
configured to do so.
Step 1 Configure the subscriber manager (SM) machine as the destination of accounting messages.
You must configure the following parameters:
• The SM IP address
• The UDP ports to which the RADIUS Listener listens
• The shared secret configured for this client in the SM configuration file
Step 2 Verify that the Accounting-Start message is sent with the correct attributes
• The attribute configured in the subscriber ID attribute mapping in the SM configuration file. See
Mapping of RADIUS Attribute to Subscriber ID, page 19-6.
• The attribute configured in the subscriber IP address attribute mapping in the SM configuration file,
the Framed-Route or the Framed-IP-Address. See Mapping of RADIUS Attribute to Subscriber IP
Address, page 19-11.
• (Optional) The attribute configured in the Subscriber package attribute mapping in the SM
configuration file. See Mapping of RADIUS Attribute to Subscriber Policy, page 19-9.
Step 3 Verify that the Accounting-Stop message is sent with the correct attributes
• The attribute configured in the subscriber ID attribute mapping in the SM configuration file. See
Mapping of RADIUS Attribute to Subscriber ID, page 19-6.
• The attribute configured in the subscriber IP address attribute mapping in the SM configuration file,
the Framed-Route or the Framed-IP-Address. See Mapping of RADIUS Attribute to Subscriber IP
Address, page 19-11.
Note It is recommended that you configure the RADIUS client to not send Authentication and
Accounting-Intermediate messages to the SM to reduce the load of packet handling.

OL-15752-01 20-1
Chapter 20 Configuring the RADIUS Client

20-2 OL-15752-01
CH A P T E R 21
Using the RADIUS Listener LEG CLU
This module describes the command-line utility (CLU) commands when the software is installed on the
Subscriber Manager (SM).
Information About the p3radius Utility

The p3radius utility displays the RADIUS Listener configurations, status, and statistics. It also provides
utilities to test RADIUS configuration and regular expression manipulation. The RADIUS Listener
configuration includes all configured NAS devices and general RADIUS Listener parameters.
The p3radius command format is p3radius <operation>.
The following table lists the p3radius operations.
Table 21-1 p3radius Operations
--show Displays all of the NAS and RADIUS
configurations and other general information
(status of ports, regular expression configuration,
etc.)
--show-statistics Displays counters of RADIUS messages handled
and number of logon operations performed.
--test-reg-exp Returns a value indicating if the regular
expression is valid or not.
--test-manipulation Validates the section definition and performs the
manipulation operation on a given field's data
against the specified section in a given
configuration file.

OL-15752-01 21-1
Chapter 21 Using the RADIUS Listener LEG CLU
Table 21-1 p3radius Operations (continued)
--test-reduction-rule Performs reduction of the input string and returns:
• The reduction result.
• The average time (in milliseconds) for a
single reduction operation. The average time
is used for performance analysis.
--test-matching-rule Performs a match of the input string against a
given regular expression and returns:
• A result indicating if there is a match or not.
• Average time (in milliseconds) for a single
matching operation. The average time is used
for performance analysis.
Table 21-2 p3radius Options
Option Abbreviation Description

--reg-exp=reg exp rule, [reg Tests the validity of regular
exp rule] expression patterns. Possible
results are:
• <regular expression rule> is
a valid regular expression
pattern.
• <regular expression rule> is
an invalid regular
expression pattern. Also
includes GNU error
information.
--performance Use with the
test-reduction-rule and
test-matching-rule operations
to calculate the average time for
a single reduction/matching
operation.

21-2 OL-15752-01
Table 21-2 p3radius Options (continued)

--file=configuration_file -f configuration_file name Tests the new/updated
name --fields=fieldname=fieldValue configuration file.
--fields=fieldname=fieldValue [ ,fieldname=fieldValue ]
[ ,fieldname=fieldValue ] --section=section name The tests are done by providing
--section=section name the following parameters:
• -f <path> or --file=<path>:
Perform the operation on a
specified configuration file.
• --field=fieldName=
fieldValue: Perform the
operation using specified
field attribute(s), and field
attribute(s) data.
<fieldName>: Property
name as defined in the fields
property.
<fieldValue>: String value
of the field property.
• section=section name:
Perform the operation on the
specified section in the
configuration file.
--input=string Provides the input string that is
being tested using the
--test-reduction-rule or the
--test-manipulation-rule
operations.
Viewing the RADIUS Listener LEG Status

The following is an example using the p3radius CLU with the show operation:
>p3radius --show
RADIUS Listener information
============================
running: true
accounting port: 1813
packet types : accounting-start, accounting-interim, accounting-stop
NASs: none
Subscriber ID
=============
user_name: radius attribute: 1 type: string
vpn: VSA Vendor-id: 1 sub attribute: 2 type: string
Separator configuration rule: Separator=user_namevpn
Subscriber IP Address
=====================
IP Configuration:
filter-id: radius attribute: 2 type: integer
VPN Configuration:
vpn: radius attribute: 26 type: integer

OL-15752-01 21-3
Properties
==========
property name: packageId
------------------------
vpn: VSA Vendor-id: 1 sub attribute: 2 type: string
user_name: radius attribute: 1 type: string
Reduction configuration rules:
Field=vpn; Pattern=.*
Field=user_name; Pattern=.*
Matching configuration rules:
Matching Pattern=.*; Matching Value=2
Matching Pattern=123; Matching Value=3
property name: monitor
----------------------
filter-id: radius attribute: 2 type: integer
Matching configuration rules:
Matching Pattern=^$; Matching Value=1
property name: upVlinkId
------------------------
property name: downVlinkId
--------------------------
>
Viewing the RADIUS Listener LEG Statistics

The following is an example of the p3radius CLU with the show-statistics operation:
>p3radius --show-statistics
Statistics:
===========
Packets Received: 0
Packets Transmitted: 0
Accounting Request: 0
Accounting Start: 0
Accounting Interim: 0
Accounting Stop: 0
Accounting Response: 0
Dropped: 0
Successful logins: 0
Failed logins: 0
Successful logouts: 0
Failed logouts: 0
>
Testing a Section in a Configuration File

The following is an example of the p3radius CLU with the test-manipulation operation:
p3radius --test-manipulation -f regExpTest.cfg --section="Radius.Subscriber ID"
--fields=user_name=,vsa=cisco.LTD.sanjose,filter-id=172.16.1.1
The following fields parameter were being extracted:
field_name=user_name, field_data=
field_name=vsa, field_data=cisco.LTD.sanjose
field_name=filter-id, field_data=172.16.1.1
reduction rules:
user_name pattern: (.*)@.*
vsa pattern: (.*).LTD(.*)
filter-id pattern: .*

21-4 OL-15752-01
separator: user_name-vsa@filter-id
Reduction iteration [0]: field data=, RegExp Pattern=(.*)@.*, concatenated string (with
separator)=-
Reduction iteration [1]: field data=cisco.LTD.sanjose, RegExp Pattern=(.*).LTD(.*),
concatenated string (with separator)=-cisco.sanjose@
Reduction iteration [2]: field data=172.16.1.1, RegExp Pattern=.*, concatenated string
(with separator)=-cisco.sanjose@
Manipulation result:-cisco.sanjose@
>
Testing a Reduction Rule

The following is an example of the p3radius CLU with the test-reduction-rule operation:
p3radius --test-reduction-rule --reg-exp=(.*)@.*,.*@(.*) --input=user@cisco.com
--performance
Pattern: '(.*)@.*'; String to reduce: 'user@cisco.com'; Reduction result: 'user'
Regular Expression operation time is 0.112 ms
Pattern: '.*@(.*)'; String to reduce: 'user@cisco.com'; Reduction result: 'cisco.com'

Regular Expression operation time is 0.061 ms

>
Testing a Matching Rule

The following is an example of the p3radius CLU with the test-matching-rule operation:
p3radius --test-matching-rule --reg-exp=ûser$,user,users --input=user@cisco.com
--performance
Pattern: 'ûser$'; String to match: 'user@cisco.com'; Matching not found
Regular Expression operation time is 0.0 ms.
Pattern: 'user'; String to match: 'user@cisco.com'; Match found

Pattern: 'users'; String to match: 'user@cisco.com'; Matching not found


>

OL-15752-01 21-5

21-6 OL-15752-01
CH A P T E R 22
Domain Association Algorithm
This module describes the algorithm used for deciding the subscriber domain to which a subscriber
should be logged on.

The RADIUS Listener decides to which domain the subscriber should be logged on, according to the
NAS that sent the Accounting-Start message.
However, if the only NAS the RADIUS Listener is configured with is the proxy device (as illustrated in
the following diagram), which is the device from where the RADIUS Listener receives messages, the
RADIUS listener cannot distinguish between NAS1 and NAS2 subscribers and cannot map them to
different subscriber domains.
Figure 22-1 Example of when the only NAS that the RADIUS Listener is configured with is the
Proxy Device
RADIUS RADIUS
Control
Links
NAS 1
SCE
Edge Router
Internet
NAS 2 Traffic SCE
157107
Links
To solve the problem of distinguishing between two NAS devices, the following algorithm is used:
• If a NAS-Identifier attribute exists in the Accounting-Start message and a NAS device is configured
with that identifier, this NAS subscriber domain configuration is used.
• If the NAS-Identifier attribute does not exist, the same test will be performed on the
NAS-IP-Address attribute. If the NAS-IP-Address attribute exists in the Accounting-Start message
the NAS device was configured, this NAS domain configuration is used.

OL-15752-01 22-1
Chapter 22 Domain Association Algorithm
• Otherwise, the domain configured for the NAS identified by the Accounting-Start packet source IP
address is used.
Using the RADIUS attributes provides the ability to distinguish between the two NAS devices.
Note If none of the three NAS identification characteristics (packet source IP, NAS-Identifier, or
NAS-IP-Address) matches the RADIUS message, the message is dropped because of RADIUS packet
processing reasons. The domain selection stage will not be performed.

22-2 OL-15752-01
P A R T 5
SCE-Sniffer RADIUS LEG

CH A P T E R 23
About the SCE-Sniffer RADIUS LEG
The Service Control Management Suite (SCMS) Subscriber Manager (SM) SCE-Sniffer RADIUS Login
Event Generator (LEG) is a software module that receives Raw Data Record (RDR) messages containing
RADIUS information from Service Control Engine (SCE) devices configured with a RADIUS Sniffer
service. The SCE-Sniffer RADIUS LEG is an extension of the SM software and runs as part of the SM
process.
Information About the SCE-Sniffer RADIUS LEG

The SCE device analyzes RADIUS traffic that traverses it (1) and reports the RADIUS transactions to
the LEG using the RDR protocol (2). The LEG associates the RDR data to subscriber properties (name,
subscriber IP, domain, and policies) and triggers a login or logout operation to the SM (3).
Figure 23-1 SCE-Sniffer RADIUS LEG Operation
SCE
Traffic (1)
RDR(2)
Login
Logout (3)
SCE-
Sniffer SM
RADIUS
157082
LEG

OL-15752-01 23-1
Chapter 23 About the SCE-Sniffer RADIUS LEG
Information About the SCE-Sniffer RADIUS LEG
RADIUS Integration Overview

This implementation of the SCE-Sniffer RADIUS LEG supports RFC 2865 (RADIUS protocol) and
RFC 2866 (RADIUS Accounting).
The LEG uses the following packet types:
• Accounting-Start—Initiates login operations (with subscriber IP, domain, and policies)
• Accounting-Interim-Update—Initiates login operations (with subscriber IP, domain, and policies)
• Accounting-Stop—Initiates logout operations
• Access-Request—Initiates domain and policies associations
• Access-Accept—Initiates login operations (with subscriber IP and policies)
The LEG uses the following attributes:
• User Name (Attribute #1)—Default attribute for subscriber ID
• NAS-IP-Address (Attribute #4)—Associates the NAS IP address as the subscriber's domain
(optional)
• Framed-IP-Address (Attribute #8)—Associates an IP address to the subscriber
• Framed-IP-Netmask (Attribute #9)—Associates an IP netmask to the subscriber
• Framed-Route (Attribute #22)—Associates an IP/IP-range to the subscriber
• NAS-Identifier (Attribute #32)—Associates the NAS identifier as the subscriber's domain
(optional)
• Acct-Status-Type (Attribute #40)—Distinguishes between the different accounting transactions.
To associate policies to the subscribers, configure the LEG with the attribute that contains the policy
information. The Vendor Specific attribute (Attribute #26) can be used to associate policies to the
subscribers in addition to all other RADIUS attributes of type string or integer.
To determine the subscriber ID, configure the LEG with the attribute that contains the subscriber ID
information. The Vendor Specific attribute (Attribute #26) can be used to determine the subscriber ID
in addition to all other RADIUS attributes of type string. By default, the User-Name (Attribute #1) is
configured to hold the subscriber ID.

23-2 OL-15752-01
CH A P T E R 24
SCE-Sniffer RADIUS LEG Functionality
This module describes the SCE-Sniffer RADIUS LEG transactions for login and logout operations
The Service Control Engine (SCE) devices analyze the RADIUS transactions and send the information
to the SCE-Sniffer RADIUS LEG that resides on the Subscriber Manager (SM). The LEG performs login
or logout operations to the SM using the information sent from the SCE devices.
• SCE-Sniffer RADIUS Functionality, page 24-1
• Information About RADIUS Attributes, page 24-2
• Information About RADIUS Packets, page 24-4
SCE-Sniffer RADIUS Functionality

The LEG supports the following integrations with the RADIUS transactions:
• Integrating with the RADIUS Accounting transactions
In this mode, the Accounting-Start and (optionally) Accounting-Interim-Update packets are used for
login operations, and (optionally) the Accounting-Stop packets are used for logout operations. This
integration mode is the simplest; therefore, if accounting transactions are used in your network it is
advisable to use this integration mode.
• Integrating with the RADIUS Authentication transactions
In this mode, the Access-Request and Access-Accept packets are used for login operations. This
mode does not support logout operations. Use this integration mode if RADIUS accounting is not
used in your network.
• Integrating with the RADIUS Accounting and Authentication transactions
This mode combines the previous two modes. Login operations use Authentication transactions, and
logout operations use Accounting transactions.

OL-15752-01 24-1
Chapter 24 SCE-Sniffer RADIUS LEG Functionality
Information About RADIUS Attributes

This section describes how subscriber properties are extracted from the RADIUS attributes.
• Subscriber ID Association, page 24-2
• Domain Association, page 24-2
• Policy Association, page 24-3
• Subscriber IP Association, page 24-3
Subscriber ID Association
By default, the attribute used for the subscriber ID association is the User-Name attribute (#1), but it can
be configured to any other attribute including the Vendor-Specific attribute (#26).
The only requirement is that the configured attribute must be of type string.
This attribute must exist in the RADIUS traffic for successful login operations, because a subscriber
cannot be introduced to the SM without its ID.
For logout operations, which are triggered by Accounting-Stop packets only, this attribute is not
mandatory, because logouts can be performed using the mapping information.
Domain Association
Note Domain association is only relevant for login operations and is optional.
Domain association is based on the Network Access System (NAS) that initiated the RADIUS
transaction. The RADIUS attributes that identify the NAS are NAS-Identifier (#32), and
NAS-IP-Address (#4). If none of the attributes exist, the LEG tries to identify the NAS using the IP
address of the NAS taken from the UDP packet.
Before a login operation occurs, the NAS properties, NAS-Identifier and NAS-IP-Address, are matched
against the configured domains or domain aliases of the SM. The login operation uses the matched
domain or domain alias as the subscriber domain.
The domain association is performed in stages, as follows:
1. If the NAS-Identifier attribute exists, and a domain name or alias is configured in the SM for the
same NAS-Identifier, the domain name or alias is used as the subscriber domain.
2. If the previous step fails, the same test is performed on the NAS-IP-Address attribute.
3. If the NAS-IP-Address does not exist as well, the same test is performed on the IP address of the
NAS.
4. If the NAS-Identifier and the NAS-IP-Address attributes are missing or does not match to an
existing SM domain or alias, the default subscriber domain is used.

24-2 OL-15752-01
Policy Association
Note Policy association is only relevant for login operations and is optional.
The user can configure policy association. You can use any RADIUS attribute for policy association,
including the Vendor-Specific attribute.
The term policy association refers to the act of setting a subscriber property according to information
extracted from the RADIUS packets. An example of policy association is setting the packageId property
of the Service Control Application for Broadband (SCA BB) solution to control the network service
level for which the subscriber is entitled.
To associate policy from a RADIUS attribute, the configured attribute must be of type string or integer.
The subscriber property values are always integers. However, if the association is based on a string
RADIUS attribute, it is mandatory to configure a mapping table. If the association is based on an integer
RADIUS attribute, a mapping table is not needed, but can be used. See Information About Configuring
the Policy Settings for more information on configuring a mapping table.
You can define a default value for the policy if the configured RADIUS attribute is missing from the
packet. The default value is valid only if the policy has not been set before (for example by other LEGs,
or the Subscriber Manager).
The Information About Configuring the Policy Settings section describes how to configure the policies.
Subscriber IP Association
The Subscriber IP Address is normally based on the Framed-IP-Address attribute, but can also be based
on the RADIUS attribute. In different topologies, the subscriber IP address specification might be sent
as a RADIUS attribute other than the Framed-IP-Address attribute.
The following algorithm extracts the IP addresses in this LEG:
1. If the user configured an attribute from which to extract the IP, the LEG will look for that attribute
in the RDR. If the attribute exists, the LEG will use the attribute as the subscriber IP address.
2. If the attribute does not exist or is not configured, the LEG will look for the Framed-Route
attributes; several Framed-Route attributes may exist. If any Framed-Route attributes exist, the LEG
will use these attributes as the subscriber IP addresses.
3. If there are no Framed-Route attributes, the LEG will look for a Framed-IP-Address attribute and a
Framed-IP-Netmask attribute. If a Framed-IP-Address attribute exists, the LEG will use this
attribute as the subscriber IP address. If both the Framed-IP-Address and the Framed-IP-Netmask
attributes exist, the operation is performed with the IP range represented by the IP address and the
IP netmask.
4. Otherwise, the LEG will perform a login without the IP address.
Note The configured attribute can be a regular RADIUS attribute or a VSA. It is possible to encode the
attribute as an integer in which case it will be a single IP address. It can also be encoded as a string and
will therefore be an IP-Address/IP-Range value: the value must be formatted as A.B.C.D/E or A.B.C.D

OL-15752-01 24-3
Information About RADIUS Packets
Note The supported format of the Framed-Route attribute is as described in RFC-2865. It must start with a
string that starts with the route itself in the format A.B.C.D/E followed by a space. Other values follow
the space, but the LEG ignores these other values.

This section describes the RADIUS packets supported by the SCE-Sniffer RADIUS LEG and their
impact on the SM.
• Accounting-Start Packet, page 24-4
• Accounting-Interim-Update Packet, page 24-4
• Accounting-Stop Packet, page 24-5
• Access-Accept Packet, page 24-5
Accounting-Start Packet
An Accounting-Start packet initiates a login operation with the following subscriber properties:
• Subscriber ID—See Subscriber ID Association, page 24-2
• Subscriber IP—See Subscriber IP Association, page 24-3
• Domain—See Domain Association, page 24-2
• Policy—See Policy Association, page 24-3
If the Accounting-Start packet does not hold the subscriber ID, the login operation is not performed and
an error message is written to the user log. All other properties (subscriber IP, domain, and policy) are
optional.
Note The Accounting-Start and Accounting-Interim-Update packets are the only packets that hold all the
subscriber properties. Use these packets whenever possible.
Accounting-Interim-Update Packet
An Accounting-Interim-Update packet initiates a login operation with exactly the same properties as the
Accounting-Start packet.
If the Accounting-Interim-Update packet does not hold the subscriber ID, the login operation is not
performed and an error message is written to the user log. All other properties (subscriber IP, domain,
and policy) are optional.
Note Use this packet when the subscribers are connected to the network for a long time in a single session.

24-4 OL-15752-01
Accounting-Stop Packet
An Accounting-Stop packet initiates a logout operation with the following subscriber properties:
Unlike the Accounting-Start packet, the subscriber ID is not mandatory in the Accounting-Stop packet.
If it does not exist, the logout is based only on the mappings information. If the Accounting-Stop packet
has a subscriber ID but does not have the mappings, all mappings of the subscriber are logged out. If
both properties are missing, the logout operation is not performed and an error message is written to the
user log.
Note The Accounting-Stop packet is the only packet that initiates a logout operation. If you need to perform
logouts, you must use this packet for integration.
Access-Accept Packet
An Access-Accept packet initiates a login operation with the following subscriber properties:
• Policy—See Policy Association, page 24-3
The subscriber ID is mandatory, subscriber IP and policy are not. If the subscriber ID is missing, the
login operation is not performed and an error message is written to the user log.
Note The Access-Accept packet does not hold any information needed for domain association. If you are
using domains, consider using the accounting packets for domain integration.

OL-15752-01 24-5

24-6 OL-15752-01
CH A P T E R 25
Installing the SCE-Sniffer RADIUS LEG
This module describes the procedures for installing and running the SCE-Sniffer RADIUS LEG. It also
describes the procedure to uninstall the SCE-Sniffer RADIUS LEG.
The SCE-Sniffer RADIUS LEG is an external component (PQI file) of the subscriber manager (SM)
software that should be installed separately using the SM command-line utilities. The SCE-Sniffer
RADIUS LEG distribution is part of the SM LEG distribution.
The installation package of the LEG includes a set of configuration files and command-line utilities for
the LEG.
• Installing the SCE-Sniffer RADIUS LEG Software, page 25-1
• Uninstalling the SCE-Sniffer RADIUS LEG, page 25-2
• Upgrading the SCE-Sniffer RADIUS LEG, page 25-2
Installing the SCE-Sniffer RADIUS LEG Software

Note Before installation, verify that the Service Control Application for Broadband (SCA BB) is installed on
all SM and SCE devices. If the application has not been installed, install the application as described in
the Cisco Service Control Application for Broadband User Guide.
Note After the installation of the PQI file, the SM will automatically restart.
Step 1 Install the PQI file of the SCE-Sniffer RADIUS LEG using the p3inst CLU.
Run the p3inst CLU from the SM CLU <sm-inst-dir>/sm/server/bin (sm-inst-dir refers to the SM
installation directory):
>p3inst --install -f rad_snif.pqi
Step 2 Edit the configuration file of the SCE-Sniffer RADIUS LEG
The name of the configuration file is rad_snif.cfg, and it is located under the configuration folder of the
SM (<sm-inst-dir>/sm/server/root/config).
It is recommended to familiarize yourself with this file immediately after the first installation, and edit
it according to your specific needs. See Configuring the SCE-Sniffer RADIUS LEG for more
information.
Step 3 Load the configuration file to the SM using the p3sm CLU

OL-15752-01 25-1
Chapter 25 Installing the SCE-Sniffer RADIUS LEG
Uninstalling the SCE-Sniffer RADIUS LEG
Run the p3sm command line utility from the SM CLU:

>p3sm --load-config
Step 4 Configure the SCE to send RDRs to the LEG
Run the RDR-formatter Command-Line Interface (CLI) in the SCE to add the LEG as a category 3 RDR
destination:
SCE2000>configure
SCE2000(config)>RDR-formatter destination SM-IP port port category number 3 priority 100
Use the same port number as defined by the RDR server in the SM. The default port number is 33001.
Note To support SM cluster topology, set the cluster VIP as the SM-IP in the above CLI command.
Uninstalling the SCE-Sniffer RADIUS LEG
Step 1 Configure the SCE to stop sending RDRs to the LEG

Run the RDR-formatter CLI command in the SCE to remove the LEG as category 3 RDR destination:
SCE2000>configure
SCE2000(config)>no RDR-formatter destination SM-IP port port
Step 2 Uninstall the SCE-Sniffer RADIUS LEG using the p3inst CLU
Run the p3inst command line utility from the SM CLU:
>p3inst --uninstall -f rad_snif.pqi
Note After the uninstall process has successfully completed, the SM will automatically restart.
Upgrading the SCE-Sniffer RADIUS LEG

The SCE-Sniffer RADIUS LEG must be upgraded when upgrading is performed between versions of the
SM as part of the SM upgrade process. The upgrade for the SCE-Sniffer RADIUS LEG should be
performed together with the upgrade process of the SM.
Step 1 Backup the configuration file of the SCE-Sniffer RADIUS LEG.

The original configuration file is deleted by the uninstall process in the next step.
Step 2 Force the SCEs to store the RDRs during the upgrade.
To force the SCEs to store the RDRs, disable the RDR Server on the SM by setting the start parameter
in the RDR Server section to false and loading the configuration by running the following CLU:

25-2 OL-15752-01
>p3sm --load-config
Step 3 Uninstall the SCE-Sniffer RADIUS LEG using the p3inst --uninstall CLU of the SM.
Step 4 Perform the upgrade of the SM as described in the Cisco SCMS Subscriber Manager User Guide.
Step 5 Install the new version of the SCE-Sniffer RADIUS LEG using the p3inst --install CLU of the SM.
Step 6 Restore the configuration files of the SCE-Sniffer RADIUS LEG.
Step 7 Make the SCEs send the RDRs that they stored during the upgrade.
To make the SCEs send the RDRs that they stored during the upgrade, enable the RDR Server on the SM
by setting the start parameter in the RDR Server section to true.
Step 8 Load the new configuration by using the p3sm --load-config CLU of the SM.

OL-15752-01 25-3

25-4 OL-15752-01
CH A P T E R 26
Configuring the SCE-Sniffer RADIUS LEG
This module describes the configuration instructions to configure the SCE-Sniffer RADIUS LEG.
The SCE-Sniffer RADIUS LEG is configured using the configuration file rad_snif.cfg, which resides
in the <sm-inst-dir>/sm/server/root/config directory (sm-inst-dir refers to the subscriber manager
(SM) installation directory).
The configuration file consists of sections headed by a bracketed section title; for example,
[SCE-Sniffer RADIUS LEG]. Each section consists of several parameters with the format of
parameter=value. The number sign (“#”) at the beginning of a line denotes that this is a remark line.
• Configuring the Subscriber ID, page 26-2
• Information About Configuring the Subscriber IP Address, page 26-3
• Information About Configuring the Policy Settings, page 26-4

The general configuration of the LEG appears under the section name [SCE-Sniffer RADIUS LEG].
The following list describes the general configuration parameters:
• start
Defines whether the SM should run the LEG at startup.
To start using the LEG, change this setting to yes.
• packet_types
Defines the RADIUS packet types to analyze. You should set this parameter according to the
integration mode you have chosen.
Possible values are any combination of: access-request, access-accept, accounting-start,
accounting-interim, and accounting-stop separated by commas.
The default value is accounting-start, accounting-interim, accounting-stop.
• log_failures
Defines whether the LEG should add messages about failures to the user log.

OL-15752-01 26-1
Chapter 26 Configuring the SCE-Sniffer RADIUS LEG
Configuring the Subscriber ID
• log_all
Defines whether the LEG should add all messages, including successful logins and logouts, to the
user log.
Note For this LEG to work correctly, use the configuration file to enable the RDR server in the SM.
Configuring the Subscriber ID

Note The Subscriber ID configuration is optional.
The subscriber ID is identified by the User-Name attribute by default. You can configure the LEG to use
any other RADIUS attribute to identify the subscriber ID, including using the Vendor-Specific attribute.
Note If you want to keep the default identification according to the User-Name attribute, you can skip this
section.
Note The configured attribute must be of data type string. When using the Vendor-Specific attribute, the
configured vendor specific subtype must be of data type string.
The section used for subscriber ID configuration is called [RADIUS.Subscriber ID]. The following list
describes the parameters:
Defines the attribute number for the subscriber ID classification.
The default value is 1 (User-Name attribute).
• radius_attribute_vendor_id
This parameter is only relevant if radius_attribute is configured to 26 (Vendor-Specific attribute).
The parameter defines the vendor ID number for the subscriber ID classification.
• radius_sub_attribute
The parameter defines the sub attribute within the vendor specific attribute that is used for
subscriber ID classification.
Defines the attribute type. Possible values for this parameter are integer or string. The default value
is string.

26-2 OL-15752-01
Information About Configuring the Subscriber IP Address
Information About Configuring the Subscriber IP Address

Note The Subscriber IP Address configuration is optional.
The subscriber IP Address is identified by the Framed-Route attributes, or the Framed-IP-Address

attribute (Framed-IP-Netmask optional) by default. The LEG can be configured to use any other
RADIUS attribute to identify the subscriber IP Address, including using the Vendor-Specific attribute
as described in the Subscriber IP Association section.
To define which attribute to use for the subscriber IP address, configure the [RADIUS.Subscriber IP
Address] section. In order to use the default values, leave the configuration remarked.
To define the attribute to be used, configure the following parameters:
Configure the radius_attribute parameter with the RADIUS attribute number. Enter the value of
26 for Vendor Specific Attributes (VSA).
The parameter defines the vendor ID number for the subscriber ID classification.
The parameter defines the sub attribute within the vendor specific attribute that is used for
subscriber ID classification.
Configure the radius_attribute_type parameter according to the RADIUS attribute format.
Possible values for this parameter are integer or string. If the type is string, you must supply a
mapping table. The default value is string.
Subscriber IP Address Configuration Example

The following is an example of the configuration section to define which attribute to use for the
subscriber IP address:
[RADIUS.Subscriber IP Address]
radius_attribute=26
radius_attribute_vendor_id=1000
radius_sub_attribute=3
radius_attribute_type=string

OL-15752-01 26-3
Information About Configuring the Policy Settings

Note The policy configuration is optional.
Policy configuration assigns policy information such as package ID, according to the RADIUS packets.
Configure the SCE-Sniffer RADIUS LEG using the policy section(s) to assign the policy information.
Note This section is optional. If you do not need to set policy information according to RADIUS packets, you
can skip this section. The SCE-Sniffer RADIUS LEG will not include any policy information when it
logs in subscribers. If the subscriber already has some policies set, the LEG will not affect it.
For each policy you want to define, you need to specify a different section named
[RADIUS.Policy.policyName]. You can use any string you want for policyName if the policy name is
unique inside the configuration file.
Each policy section has the following parameters:
Defines the attribute number that holds the policy information.
The parameter defines the vendor ID number that holds the policy information.
The parameter defines the sub attribute of the vendor specific attribute that holds the policy
information.
Defines the type of the attribute.
Possible values are string or integer.
• default_value
Defines the default value to set in case the attribute is not found in the traffic.
The default value is set only if this policy has not been already set, for example by other LEG
interfaces.
This parameter is optional. If it does not exist, a default value will not be set for this policy.
• policy_name
Defines the name of the subscriber property. For instance, the packageId property defines the
policies of the SCA BB solution.

26-4 OL-15752-01
Note The policy_name parameter is case sensitive and must be written exactly as defined by the SCA BB
Console. For example, packageId, monitor, upVlinkId, or downVlinkId.
• mapping_table.<key>=<value>
A set of values (key, value) used to map the data retrieved from the RADIUS attribute to the policy
index configured by the application.
Note The mapping table key is case sensitive and must be written exactly as it exists in the RADIUS packets.
Policy Configuration Example

The following configuration section associates the packageId property of the SCA BB solution with a
Vendor Specific attribute of the RADIUS packet:
[RADIUS.policy.packageId]
radius_attribute=26
radius_attribute_vendor_id=1000
radius_sub_attribute=2
radius_attribute_type=string
default_value=1
policy_name=packageId
mapping_table.gold=11
mapping_table.silver=12
mapping_table.bronze=13
This configuration indicates that if the configured RADIUS attribute of data type string holds the value
gold, the package ID that will be introduced to the SM will have the value of 11. If the configured vendor
specific attribute does not appear in the traffic, the package ID that will be introduced to the SM will
have the value 1.

OL-15752-01 26-5

26-6 OL-15752-01
CH A P T E R 27
Using the SCE-Sniffer RADIUS LEG CLU
This module describes the Command-Line Utilities (CLU) to retrieve information and statistics about
the LEG
Information About the SCE-Sniffer RADIUS LEG Utility

The SCE-Sniffer RADIUS LEG contains its own CLU commands, called p3radiussniff, for retrieving
information and statistics about the LEG.
The p3radiussniff utility displays the LEG configuration and statistics. The command format is
p3radiussniff <operation> .
The following table lists the p3radiussniff operations
Table 27-1 p3radiussniff Operations
--show Displays all of SCE-Sniffer RADIUS LEG
configuration and status
--show-statistics Displays counters of RADIUS messages handled
and number of login/logout operations performed
--show-version Displays the SCE-Sniffer RADIUS LEG version
number
arguments with a short explanation of their
meanings.
• Viewing the SCE-Sniffer RADIUS LEG Status, page 27-1

• Viewing the SCE-Sniffer RADIUS LEG Version, page 27-2
• Viewing the SCE-Sniffer RADIUS LEG Statistics, page 27-2
Viewing the SCE-Sniffer RADIUS LEG Status

The following example illustrates the p3radiussniff CLU using the show operation:

OL-15752-01 27-1
Chapter 27 Using the SCE-Sniffer RADIUS LEG CLU
Information About the SCE-Sniffer RADIUS LEG Utility
>p3radiussniff --show
SCE-Sniffer RADIUS LEG:
======================
Active: true
RADIUS packet types:
accounting_start
accounting_interim
accounting_stop
Subscriber ID Association
Attribute: 1
Policy Association:
attribute=26
vendorIdAttribute=1000
subAttribute=2
atributeType=string
defaultValue=1
policyName=packageId
>
Viewing the SCE-Sniffer RADIUS LEG Version

The following example displays the p3radiussniff CLU using the show-version operation:
>p3radiussniff --show-version
SCE-Sniffer RADIUS LEG 3.1.0 Build 176
>
Viewing the SCE-Sniffer RADIUS LEG Statistics

The following example displays the p3radiussniff CLU using the show-statistics operation:
>p3radiussniff --show-statistics
SCE-Sniffer RADIUS LEG statistics
=================================
Total Received RDRs: 12
Accounting RDRs: 12
Accounting-Start RDRs: 6
Accounting-Interim RDRs: 0
Accounting-Stop RDRs: 6
Access RDRs: 0
Access-Request RDRs: 0
Access-Accept RDRs: 0
Invalid RDRs: 0
Successful logouts: 6
Failed logins: 0
Failed logout: 0
>

27-2 OL-15752-01
P A R T 6
MPLS/VPN BGP LEG

CH A P T E R 28
About the MPLS/VPN BGP LEG
The Service Control Management Suite (SCMS) Subscriber Manager (SM) MPLS/VPN BGP Login
Event Generator (LEG) is a software module that dynamically provides the MPLS label for each VPN
using the border gateway procotol (BGP). It listens to the BGP traffic to determine the correct MPLS
label.
• MPLS/VPN Overview, page 28-1
• MPLS/VPN BGP LEG Overview, page 28-2
MPLS/VPN Overview
Internet service providers that have a common network of multiple server sites with IP interconnectivity
deployed on a shared infrastructure can be securely connected using a Virtual Private Network (VPN).
A VPN can secure a shared network connection by employing technologies such as authentication,
encryption, and tunneling. The VPN traffic is encapsulated and transparently sent from one site to
another enabling the traffic to be secured by encryption.
Customers that connect to the ISP using the VPN topology experience direct communication to the VPN
sites as though they have their own private network even though their traffic is traversing a public
network infrastructure and sharing the same infrastructure with other businesses.
Multiprotocol Label Switching (MPLS) is an emerging industry standard for implementing tag
switching technology on high-speed routers in large IP networks. MPLS is designed to carry information
of different protocols over a network and brings some of the advantages of circuit-switched networks to
switched IP networks.
Connecting the MPLS protocol with VPN, the MPLS/VPN topology consists of a set of sites that are
interconnected by means of an MPLS provider core network. At each site within the MPLS edge, one or
more Customer Edge (CE) routers are attached to one or more Provider Edge (PE) routers. The Provider
(P) router within the core routes packets to the PE routers. PE routers use the Border Gateway Protocol
to communicate dynamically with each other.
Figure 28-1 illustrates the MPLS/VPN topology:

OL-15752-01 28-1
Chapter 28 About the MPLS/VPN BGP LEG
MPLS/VPN BGP LEG Overview
Figure 28-1 MPLS/VPN Topology
CE CE
VPN A P VPN A
Site 2 PE Site 1
10.0.2.x 10.0.1.x
PE
P
CE CE
VPN B VPN B
Site 2 Site 1
157096
Service Provider's
10.0.2.x MPLS core 10.0.1.x
Some of the benefits of MPLS-based VPNs are seamless integration with customer intranets and
increased scalability with numerous sites for each VPN and many VPNs for each service provider.

The MPLS/VPN BGP LEG solution consists of two components:
• BGP LEG—A UNIX daemon process that runs the BGP protocol to determine the BGP routes. This
process runs under the root privileges.
• Subscriber Manager (SM)—The Subscriber Manager server stores subscriber and VPN information
and updates the Service Control Engines (SCEs). The BGP adapter, an SM component, receives the
routes from the BGP LEG and handles the adjustments to the regular VPN login/logout operations.
The SM and the BGP LEG are different processes that run on the same machine. The connection between
the components is based on the PRPC protocol.
Figure 28-2 illustrates the MPLS/VPN BGP LEG solution:

28-2 OL-15752-01
Figure 28-2 MPLS/VPN BGP LEG Solution
PE PE PE PE
BGP
UNIX Machine
add_route
SM PRPC BGP LEG
del_route
PRPC
SCE SCE SCE SCE
157051
The BGP LEG also supports receiving BGP updates from a Route Reflector (RR), instead of from each
PE router separately. The BGP LEG can receive updates from a Route Reflector and from PEs that are
not covered by the Route Reflector at the same time.
VPN Entity
A VPN entity is a group of VPN sites. The following parameters define a VPN site:
• The Provider Edge (PE) router that is connected to the VPN site. The IP address of the loopback
interface identifies the router.
• An identifier for the VPN Virtual Routing and Forwarding (VRF) table. Either the Route
Distinguisher (RD) of the VRF or the Route Target (RT) that is used for exporting or importing
routes
The PE router assigns MPLS labels for each VPN site. The BGP protocol uses the MPLS labels to
publish the VPN routes to the other PE routers. The BGP LEG listens to the BGP traffic, extracts the
MPLS label, and adds the label to the VPN data in the SM database.

OL-15752-01 28-3
VPN Identifier (RD or RT)

The VPN can be identified using either the Route Distinguisher (RD) attribute or the Route Target (RT)
attribute. It is necessary to decide which attribute best reflects the VPN partitioning, and then configure
the SM accordingly. Note that the configuration is global for all the VPNs, i.e. all VPNs must be
identified by the same attribute.
The Route Distinguisher (RD) is most commonly used to identify the distinct VPN routes of separate
customers who connect to the provider. Therefore, in most cases the RD is a good partition for the VPNs
in the network. Since the RD is an identifier of the local VRF, and not the target VRF, it can be used to
distinguish between VPN sites that transfer information to a common central entity (e.g. a central bank,
IRS, Port Authority, etc.).
The Route Target (RT) is used to define the destination VPN site. Though it is not intuitive to define the
VPN based on its destination routes, it might be easier in some cases. For example, if all the VPN sites
that communicate to a central bank should be treated as a single VPN, it is worthwhile to use the RT as
the VPN identifier.
It is important to note that the configuration is global. Thus, if at some point in time, a certain VPN needs
to be defined by RD, then all the VPN must be defined by RD as well. This is a point to consider when
designing the initial deployment.
BGP LEG Scenario

The following scenario depicts the operation of the MPLS/VPN mode:
1. The Subscriber Manager starts up.
2. The BGP LEG establishes a PRPC connection to the Subscriber Manager.
3. The administrator imports the VPNs to the Subscriber Manager using a CSV file. The administrator
specifies the following properties for each VPN:
– VPN name
– A list of VPN sites. Each VPN site is defined by:
– VPN ID—The RD or RT that identifies the VPN's VRF
– The IP address of the loopback interface of the PE router
– SM domain
4. The administrator imports the VPN-based subscribers to the Subscriber Manager using another CSV
file. The administrator specifies the following properties for each subscriber:
– Subscriber name
– A list of private IPs within the VPN using the syntax 'IP@VPN' (or a list of communities within
a VPN as described in CE as Subscriber, page 28-5).
– SM domain
– A list of application properties. For example, the Service Control Application for Broadband
(SCA BB) package ID, as described in the Cisco Service Control Application for Broadband
(SCA BB) User Guide.
5. The administrator configures the BGP LEG by specifying the PE routers that should be connected
to it.
6. PE routers distribute routing information to the BGP LEG.

28-4 OL-15752-01
7. The BGP LEG analyzes BGP sessions and extracts the relevant data, such as RD/RT, MPLS label,
and the loopback IP of the PE router.
8. The BGP LEG updates the VPN in the SM with the added or removed MPLS label.
9. The Subscriber Manager updates its database with the new VPN information and updates all of the
SCE devices in the domain.
CE as Subscriber
An MPLS-VPN based subscriber can be defined to handle the traffic of a specifc Customer Edge (CE)
router. The BGP community field is used to correlate the private IP routes with the CE router. The
subscriber is configured with a list of communities within the VPN using the syntax
‘community@VPN’.
When the BGP LEG analyzes the BGP session, it also extracts the community field, and adds all the IP
routes in the BGP message to the subscriber that contains the same community field. This functionality
takes place in addition to adding the VPN information to the SM as described in BGP LEG Scenario,
page 28-4.

OL-15752-01 28-5

28-6 OL-15752-01
CH A P T E R 29
Installing the MPLS/VPN BGP LEG
This module describes the process for installing and uninstalling the SM MPLS/VPN BGP LEG.
The SM MPLS/VPN BGP LEG is an external component that should be installed on the SM. The SM
MPLS/VPN BGP LEG distribution is part of the SM LEG distribution.
The SM MPLS/VPN BGP LEG installation package includes a set of configuration files and the
Command-Line Utility (CLU).
The SM MPLS/VPN BGP LEG can be installed only on Red Hat Linux platforms.
• Installing the MPLS/VPN BGP LEG Software, page 29-2
• Adding a VCS Resource to the BGP LEG, page 29-2
• Removing a VCS Resource from the BGP LEG, page 29-3
Package Contents
The following tables describe the contents of the SM MPLS/VPN BGP LEG distribution package
supplied by Cisco:
Table 29-1 SM MPLS/VPN BGP LEG Distribution Package Contents
Path File Name Description

DIST_ROOT/bgp_leg SM MPLS/VPN BGP LEG files
bgp_leg.tar.gz SM MPLS/VPN BGP LEG
distribution
install-bgp-leg.sh SM MPLS/VPN BGP LEG
installation script
linux-def.sh Linux specific definitions script
sm-common.sh General installation script

OL-15752-01 29-1
Chapter 29 Installing the MPLS/VPN BGP LEG
Installing the MPLS/VPN BGP LEG Software
Installing the MPLS/VPN BGP LEG Software

Step 1 Copy the SM LEG distribution file to the SM machine and extract it with the gunzip command.
>gunzip SM_LEG_3.1.5_Bbbb.tar.gz
>tar –xvf SM_LEG_3.1.5_Bbbb.tar.gz
>cd bgp_leg
Step 2 Run the BGP LEG installation script.
#/install-bgp-leg.sh
The installation script automatically installs the SM MPLS/VPN BGP LEG on the SM and runs the OS
specific definitions scripts according to your installation's operating system.
Note The installation script must run under root privileges.
Step 3 Add a VCS resource for the BGP LEG
Adding a VCS Resource to the BGP LEG

In a Subscriber Manager cluster topology, the Veritas Cluster Server (VCS) should monitor the BGP
LEG process to verify that the process is running. To do so, you must configure the VCS with a resource
that monitors and controls the LEG.
Step 1 Import the OnOnlyProcess agent's type from file:

/opt/VRTSvcs/bin/OnOnlyProcess/OnOnlyProcess.cf.
Step 2 Add an OnOnlyProcess resource called "BGP_LEG" to the service group.
Step 3 Run the >ps -ea -o pid,s,args command via telnet on each one of the servers.
Step 4 Look for the line containing "bgpleg" in the text.
This line contains the path and arguments of the BGP LEG to be used in the next step.
Step 5 Define the OnlineCmd, PathName, and Arguments parameters:
• OnlineCmd—Type the BGP LEG start command, for example:
/opt/pcube/sm/server/bin/p3bgp --start
• PathName—Type the BGP LEG process path (from the previous step), for example:
/opt/pcube/sm/server/addons/bgpleg/bgpleg
• Arguments—Type the BGP LEG process arguments (from the previous step), for example:
-launch /opt/pcube/sm/server/root/config/p3bgpleg.cfg
Step 6 Click OK.
The following figure shows the Add Resource window:

29-2 OL-15752-01
Removing a VCS Resource from the BGP LEG
Figure 29-1 Add VCS Resource Window
Note The arguments line might seem shorter than the actual full argument value, which is perfectly
acceptable.

Step 1 Right-click the BGP LEG resource icon you want to remove.
Step 2 From the drop-down list, choose Delete.
Figure 29-2 Removing a VCS Resource

OL-15752-01 29-3
Note The BGP LEG will be inactivated if there are no VCS resources. To activate the BGP LEG, there must
be at least one resource.

29-4 OL-15752-01
CH A P T E R 30
Configuring the MPLS/VPN BGP LEG
This module provides the configuration instructions to configure the MPLS/VPN BGP LEG
The SM MPLS/VPN BGP LEG is configured using the configuration file p3bgpleg.cfg file, which
resides in the sm-inst-dir/sm/server/root/config directory (sm-inst-dir refers to the SM installation
directory). The configuration file is loaded only upon the SM MPLS/VPN BGP LEG startup.
The configuration file holds the IP addresses of the PEs from which the routing information is gathered.
When you reload the configuration file, all the BGP connections terminate and the BGP LEG waits for
connections to be re-established from the IP addresses configured in the configuration file.
The configuration file consists of sections headed by a bracketed section title such as [General] for the
general configuration section. Each section consists of one or more parameters having the format
parameter=value. The number sign ("#") at the beginning of a line signifies that it is a comment.
• Configuring the MPLS/VPN BGP LEG Settings, page 30-1
• Configuration File Example, page 30-2
• Configuring the SM for the MPLS/VPN BGP LEG, page 30-2
Configuring the MPLS/VPN BGP LEG Settings

This section describes the configuration file settings for each section.
The [General] section contains the following parameters:
• as-num
Defines the autonomous system number of the BGP LEG. This parameter is mandatory and has no
default value.
Possible values are 1 to 65535.
• max-route-burst
Defines an estimation of the expected burst of routes upon PE connection/refresh-all.
This parameter sets the PRPC buffer size between the BGP LEG and the SM.
The parameter is mandatory and has a default value of 100,000 routes in the p3bgpcfg configuration
file.

OL-15752-01 30-1
Chapter 30 Configuring the MPLS/VPN BGP LEG
Configuration File Example
The [PE.xxxxxxxx] section holds the PE or Route Reflector information. Each PE section must include
a unique PE/Route Reflector name. The section contains the following parameters:
• access
Defines the IP address or addresses that the PE/Route Reflector accesses (in dotted notation). It is
mandatory to configure at least one access IP address. Additional IP addresses, if needed, should be
on the same line, separated by comma. The same IP address cannot appear in two PE sections.
• as-num
Defines the autonomous system number connected to the PE/Route Reflector. This parameter is not
required. If not specified, the as-num defined in the [General] section is used.

The following example illustrates the MPLS/VPN BGP LEG configuration file:
[General]
as-num=255
max-route-burst=100000
[PE.site104]
access=10.56.211.80, 10.0.1.2, 10.55.123.56
[PE.site110]
access=10.28.233.129
as-num=110
[PE.10.56.211.81]
access=10.56.211.81
Configuring the SM for the MPLS/VPN BGP LEG

You must configure the Subscriber Manager to support the SM MPLS/VPN BGP LEG. The SM
configuration file, p3sm.cfg contains a configuration section for MPLS/VPN called [MPLS/VPN]. The
section contains the following parameters:
• vpn_id
Defines the BGP attribute that is used to identify the VPNs.
Possible values for this parameter are RD and RT.
The default value is RT.
• log_all
Defines the logging level of the BGP LEG.
Possible values for this parameter are true or false.
The default value is false.
If this parameter is set to true, the SM logs all received BGP packets. Set this parameter to true
during the integration/testing phase.
For further information on configuring the SM, see the Cisco SCMS Subscriber Manager User Guide.

30-2 OL-15752-01
CH A P T E R 31
Using the MPLS/VPN BGP LEG CLU
This module describes the MPLS/VPN BGP LEG command-line utility (CLU).
Information About the MPLS/VPN BGP LEG CLU

The p3bgp utility controls the operation of the BGP LEG and displays its status. The command format
is p3bgp <operation>[parameter]
The following table lists the p3bgp operations:
Table 31-1 p3bgp Operations
--start Starts the BGP LEG
--stop Stops the BGP LEG
--restart Restarts the BGP LEG
--status Displays a short status line for each PE/RR
--show Displays a detailed status for a specific PE/RR
--show-all Displays a detailed status for each PE/RR
--refresh Sends a refresh request to specific PE/RR to
receive updated information on all routes
--refresh-all Sends a refresh request to all PE/RR to receive
updated information on all routes. Use this
operation when the PE/RR is disconnected from
the LEG and you want to make sure that all the
BGP information is propagated to the SCE
devices. The refresh is for new information only;
obsolete labels are not checked for validity.

OL-15752-01 31-1
Chapter 31 Using the MPLS/VPN BGP LEG CLU
Table 31-1 p3bgp Operations (continued)
--force-sync Used together with --refresh-all. Sends a refresh
request to all PE/RR to receive updated
information on all routes, and then synchronizes
this information with all SCE devices. After this
operation is completed, the SCE devices are
updated with the BGP information. Use this
operation when the PE/RR is disconnected from
the LEG and you want to make sure that all the
BGP information is propagated to the SCE
devices. This operation also makes sure that
obsolete labels are removed from the SCE devices.
--load-config Loads the configuration file to the BGP LEG. This
operation also restarts the BGP LEG.
--help Displays the available p3bgp commands
BGP LEG Status

The following is an example of the p3bgp command-line utility using the status operation:
ID Peer IP PE Name Updates Notify K.Alive K.Alive Hold Time

recv recv sent recv
1 1.2.3.4 PE101 150 0 58 57 157
2 1.2.3.5 PE102 183 0 34 33 77
The following list is a description of the status operation output:

• Peer IP—The IP of the PE/RR that is connected to the LEG
• PE name—The name of the PE/RR as configured in the configuration file
• Updates recv—A counter for all the BGP updates received from this PE/RR
• Notify recv—A counter for all the BGP notifications received from this PE/RR
• K.Alive sent—A counter for all the BGP keep alives sent to this PE/RR
• K.Alive recv—A counter for all the BGP keep alives received from this PE/RR
• Hold Time—The remaining time-out for the next keep alive
BGP LEG Detailed Status

The following is an example of the p3bgp command line utility using the show operation on a specific
PE router named PE101:
1 : PE101
connects : 1
recv UPDATE : 150
recv KEEPALIVE : 57
sent KEEPALIVE : 58
recv NOTIFY : 0

31-2 OL-15752-01
current holdtime : 157

TCP sndwnd : 16384
TCP rcvwnd : 87380
Connection up time : 0 Days, 1 Hrs, 7 Min, 59 Sec
refresh requests : 2
recv PE AddRoute messages : 2
send SM AddRoute messages : 10
send SM not connected : 0
BGP state : Established
The following list is a description of the show operation output:
• connects—The number of successful connections established with this PE/RR since the LEG is up.
• recv UPDATE—A counter for all the BGP updates received from this PE/RR
• recv KEEPALIVE—A counter for all the BGP keep alives received from this PE/RR
• sent KEEPALIVE—A counter for all the BGP keep alives sent to this PE/RR
• recv NOTIFY—A counter for all the BGP notifications received from this PE/RR
• current holdtime—The remaining time-out for the next keep alive
• TCP sndwnd—The TCP send window buffer size
• TCP rcvwnd—The TCP receive window size
• Connection up time—The time since the connection to this PE/RR was established
• refresh requests—A counter for the number of refresh requests requested for this PE/RR
• recv PE AddRoute messages—A counter for BGP add-route messages received from the PE/RR
• send SM AddRoute message—A counter for successful add routes invocations performed on the SM
for this PE/RR
• send SM not connected—A counter for SM invocations that were kept in an internal buffer due to
disconnected SM
• BGP state—The state of the BGP connection to this PE/RR

OL-15752-01 31-3

31-4 OL-15752-01
P A R T 7
SOAP LEG
CH A P T E R 32
About the SOAP LEG
This module describes the SOAP LEG software module.
Information About the SOAP LEG

The Service Control Management Suite (SCMS) Subscriber Manager (SM) SOAP Login Event
Generator (LEG) is a software module that can query an external server via the Simple Object Access
Protocol (SOAP) in order to obtain additional information for the subscribers that were logged-in to the
SM via various APIs and LEGs. The main purpose of the SOAP LEG is to define the policy of the
subscriber based on the input data, the package association configuration, and the query results.
The LEG can query any external server via the SOAP communication protocol if the external server
implements an interface defined by the SCMS SM SOAP LEG.
The SCMS SM SOAP LEG supports SOAP 1.1.
The SCMS SM SOAP LEG is an extension of the SM software and runs as part of the SM.
• SOAP Integration Overview, page 32-1
• Common Topologies, page 32-3
SOAP Integration Overview

The SM activates the SOAP LEG in order to obtain the policy value (or part of the policy value) for the
subscribers that are already logged in to the SM.
With the data that the SOAP LEG receives from the SM, it creates a SOAP request, which it issues to
the external server in order to retrieve the policy value. After the external server replies, the SOAP LEG
determines the policy value according to the input data, the package association configuration, and the
query results. It then initiates a subscriber login to the SM. For more information about the package
association, see Information about Configuring the Package Association, page 34-2.
• Query Interface, page 32-2
• Secure Requests, page 32-2
• Implementing Query Interface at the Server, page 32-2

OL-15752-01 32-1
Chapter 32 About the SOAP LEG
Query Interface
The SOAP installation package includes a WSDL file. This WSDL file defines the SOAP LEG query to
the external server:
QuerySubscriberOut querySubscriber(QuerySubscriberIn subIn)
The QuerySubsriberIn parameter contains the following data:
• subscriberId—Contains the ID of the subscriber
• mappings—Contains the Network IDs of the subscriber
• keys/values—May contain additional data that the external server may need in order to perform the
query
The Web Server responds to the query and SOAP LEG analyzes the results. The output of the Web Server
(QuerySubscriberOut) consists of the following elements:
• subscriberId—Contains the ID of the subscriber
• mappings—Contains the Network IDs of the subscriber
• keys/values—May contain additional data that the SOAP LEG may need in order to determine the
package value
• propertyKeys/propertyValues—May contain subscriber properties; for example, packageId or
monitor.
Note that keys and values are used internally by the LEG for the package association procedure and are
not passed to the SM when the subscriber is logged in.
Upon receiving a reply from the Web Server, the SOAP LEG adds the query output values to the query
input values. Following this, if the SOAP LEG is configured to do so, the LEG uses this data as the input
for the package association procedure. See Information about Configuring the Package Association,
page 34-2.
Secure Requests
The SOAP LEG is able to issue a secure request to the external server using the UsernameToken profile
as defined in the WS-Security specification. Specifically, it attaches username and password to every
SOAP request it sends. For further information on configuring the username and password, see Using
the SOAP LEG CLU, page 35-1.
Note The SOAP LEG supports only text passwords.
Implementing Query Interface at the Server

Integrating the external server with the SOAP LEG is a two stage process:
1. Compile the provided WSDL file using one of the various tools available. For example, Apache
Axis can be used ( http://ws.apache.org/axis/). The WSDL file is included in the Cisco WSDL
module.
2. Provide the implementation of the querySubscriber function according to the server business logic.

32-2 OL-15752-01
Common Topologies
You can use the SOAP LEG in any SM topology, providing it is possible to supply the LEG with the
information it needs in order to perform the query to the policy server and determine the subscriber
policy.
The following figures show the most common topologies.
The following figure shows the topology with the SM API:
Figure 32-1 SOAP Topology with SM API
SM
SM
CORE
1. Login
DHCP sniffer
LEG
2. handleSubscriber
SOAP
server
3. Query subscriber
4. Login
SOAP LEG 210083
The SM API performs a login operation to the SM (1). The SM identifies that the SOAP LEG needs be
activated, and therefore it does not perform a subscriber login at this stage. TheSM core passes the
information received from the SM API to the SOAP LEG (2). The SOAP LEG queries the SOAP server
and identifies the relevant packageId based on the configuration, input parameters, and the query results
(3). The SOAP LEG then performs a login operation to the SM (4).

OL-15752-01 32-3
The following figure shows the topology with the DHCP Sniffer LEG:
Figure 32-2 SOAP LEG Topology with DHCP Sniffer LEG
DHCP
CMTS SCE server
1. DHCP traffic
2. DHCP RDRs
SM
SM
CORE
3. Login
DHCP sniffer
LEG
4. handleSubscriber
SOAP
server
5. Query subscriber
6. Login
SOAP LEG
210081
The DHCP traffic passes through the SCE (1), which sends a DHCP RDR to the DHCP Sniffer LEG (2).
The DHCP Sniffer LEG extracts the relevant information and performs a login operation to the SM (3).
The SM identifies that the SOAP LEG needs to be activated, and therefore it does not perform a
subscriber login operation at this stage. The SM core passes the information received from the DHCP
Sniffer LEG to the SOAP LEG (4). The SOAP LEG queries the SOAP server and identifies the relevant
packageId based on all the information received and the query results (5). The SOAP LEG then performs
a login operation to the SM (6).

32-4 OL-15752-01
The following figure shows the topology with the DHCP Lease Query LEG:
Figure 32-3 SOAP LEG Topology with DHCP Lease Query LEG
SCE
1. unknown traffic
2. pull
SM
SM
CORE DHCP
server
3. handle 4. Query
subscriber subscriber
5. Login
Lease query
LEG
8. Login 6. handle
subscriber
SOAP
server
7. Query subscriber
SOAP LEG 210082
Unknown traffic passes through the SCE (1), which issues a pull request to the SM (2). The SM issues
an anonymous-pull-request to the DHCP Lease Query LEG (3). The DHCP Lease Query LEG then
queries the DHCP server (4), after which it performs a login operation to the SM (5). The SM identifies
that the SOAP LEG needs to be activated, and therefore it does not perform a subscriber login at this
stage. The SM Core passes all of the information received from the DHCP Lease Query LEG to the
SOAP LEG (6). The SOAP LEG queries the SOAP server and identifies the relevant packageId based
on the information received and the query results (7). The SOAP LEG then performs a login operation
to the SM (8).

OL-15752-01 32-5

32-6 OL-15752-01
CH A P T E R 33
Installing the SOAP LEG
This module describes the installation process for installing the SOAP LEG. It also describes the
uninstall procedure.
The SOAP LEG is an external component (PQI) that should be installed on the subscriber manager (SM).
The SOAP LEG distribution is part of the SM LEG distribution.
The SOAP LEG installation package includes a set of configuration files, a WSDL file containing a
query definition, and the Command-Line Utility (CLU).
Installing the SOAP LEG Software

Note Before installation, verify that the Service Control Application for Broadband (SCA BB) is installed on
all SM and SCE devices. If the application has not been installed, install the application as described in
the Cisco Service Control Application for Broadband User Guide.
Note After the installation of the PQI file, the SM will automatically restart.
Step 1 Install the PQI file of the SOAP LEG

Run the p3inst command line utility from the SM CLU <sm-inst-dir>/sm/server/bin (sm-inst-dir
refers to the SM installation directory):
>p3inst --install -f soapleg.pqi
The soapleg.pqi file can be found in the soap_leg folder of the LEGs distribution.
Step 2 Edit the configuration files of the SOAP LEG
The SOAP LEG includes two configuration files under the configuration folder of the SM
(<sm-inst-dir>/sm/server/root/config):
• soap_leg.cfg—Configures the general attributes of the LEG
• soap_pkg.cfg—Configures the rules for package assignment
Note It is recommended to familiarize yourself with these files immediately after the first installation and edit
them according to your specific needs. See Configuring the SOAP LEG for more information.

OL-15752-01 33-1
Chapter 33 Installing the SOAP LEG
Uninstalling the SOAP LEG
Step 3 Load the configuration file to the SM

Run the p3sm command line utility from the SM CLU:
>p3sm --load-config
Note After the install process has successfully completed, the SM will automatically restart.
Uninstalling the SOAP LEG

Step 1 Run the p3inst command line utility from the SM CLU
>p3inst --uninstall -f soapleg.pqi
Note After the uninstall process has successfully completed, the SM will automatically restart.
Upgrading the SOAP LEG

The SOAP LEG and SM versions must be identical; therefore, the SOAP LEG must be upgraded as part
of the SM upgrade process. The upgrade for the SOAP LEG should be performed together with the
upgrade process of the SM.
Step 1 Backup the configuration files of the SOAP LEG.

Step 2 Uninstall the SOAP LEG by running the p3inst CLU.
>p3inst --uninstall -f <soapleg.pqi>
Note After the uninstall process has successfully completed, the SM automatically restarts.
Step 3 Perform an upgrade of the SM as described in the Cisco SCMS Subscriber Manager User Guide.
Step 4 Install the new version of the SOAP LEG by running the p3inst CLU.
>p3inst --install -f <soapleg.pqi>
Step 5 Restore the configuration files of the SOAP LEG using the backup configuration files from Step 1.
Step 6 Load the new configuration of the SM by running the p3sm CLU.
>p3sm --load-config

33-2 OL-15752-01
CH A P T E R 34
Configuring the SOAP LEG
This module provides the configuration instructions to configure the SOAP LEG.
The SOAP LEG is configured using two configuration files, soap_leg.cfg and soap_pkg.cfg, which
reside in the sm-inst-dir/sm/server/root/config directory (sm-inst-dir refers to the SM installation
directory). The configuration file is loaded only upon SCMS SM SOAP LEG startup.
The configuration files consist of sections headed by a bracketed section title; for example,
[SOAP-LEG] for the SOAP LEG configuration section. Each section consists of one or more parameters
having the format parameter=value. The number sign ("#") at the beginning of a line signifies that it is
a comment.
The general configuration of the SOAP LEG resides in soap_leg.cfg. The dynamic package association
configuration resides in soap_pkg.cfg.
• Information About Configuring the SOAP LEG Settings, page 34-1
• Information about Configuring the Package Association, page 34-2
Information About Configuring the SOAP LEG Settings

• Configuring the SOAP LEG Settings, page 34-1
• Configuration File Example, page 34-2
Configuring the SOAP LEG Settings

The [SOAP-LEG] section in the configuration file defines the behavior of the SOAP LEG and contains
the following parameters:
• start
Defines whether to start the LEG at SM startup.
Possible values for this parameter are true and false.
• server_url
The URL of the policy server the LEG will query.
There is no default value.
This parameter must be configured for proper LEG functioning.

OL-15752-01 34-1
Chapter 34 Configuring the SOAP LEG
Information about Configuring the Package Association
• log_failed_queries
Defines whether the LEG will log messages that are issued for failed queries.
The default value is true.
• log_all_queries
Defines whether the LEG will log messages for every query sent and any reply received.
Note This parameter should only be set to true when troubleshooting.
The [Package] section in the configuration file contains the following parameter:
• pkg_cfg_file
Defines the configuration file to be used by the converter. The path must be relative to the config
directory.
The default value is soap_pkg.cfg.

The following example illustrates the SOAP LEG configuration file:
[SOAP-LEG]
server_url=http://1.1.1.1:8080/services/QueryServiceSoap.asmx
log_failed_queries=true
log_all_queries=false
[Package]
pkg_cfg_file=soap_pkg.cfg

• Configuring the Package Assocation, page 34-2

• Package Association Example, page 34-4
Configuring the Package Assocation

This configuration file is intended for the customization of the output produced by the SOAP LEG.
The LEG concatenates the data extracted from the configured labels and creates a package name.
To extract the package information data from the SOAP package, the soap_pkg.cfg configuration file
must define the conversion map of package-names to the package IDs of the SCA BB application.
The [SOAP.Policy.Package] section of the configuration file contains the following parameters:

34-2 OL-15752-01
• policy_name_format
This parameter is a comma-separated list that specifies the labels that contain the data from which
the policy name is comprised. The LEG converter searches for the labels within the received
arguments and concatenates them according to the specified order. A value of LABEL_A,
LABEL_B indicates that the SOAP LEG needs to concatenate values that reside under the
LABEL_A and LABEL_B labels.
Defines the separator value to use when concatenating options.
The default value is '_'.
• default_value
Defines the default value to use when it is not possible to associate the created policy name with any
of the configured policy names.
Defines whether a login can be performed when no policy is found for assignment.
The default value is true.
Defines the package property key to use for policy assignment.
The default value is packageId.
SCA BB Console. For example, packageId, upVlinkId, or downVlinkId.
• mapping_table.<key>=<value>
A set of values (key,value) used to map the package information determined by the SOAP LEG and
the package ID index that the SCA BB application uses.
Note Every policy name is preceded by the mapping_table. key. For example:
mapping_table.PolicyLabel1=11
mapping_table.PolicyLabel2=12
The [SOAP.Policy Logging] section of the configuration file contains the following parameters:
• log_missing_policy_name
Defines whether log messages will be issued when no policy was found.
• log_all

OL-15752-01 34-3
Note Set the log_all parameter to true only when troubleshooting.
• log_default_policy_assignment
in default_value)
Package Association Example

Assuming that the package information appears inside labels TYPE and DOMAIN, configure the order
of the labels for the policy name format as follows:
policy_name_format=TYPE,DOMAIN
Assuming that label TYPE (returned as a query reply) contains the type of package (gold, silver, or
bronze) and label DOMAIN (passed as an input parameter) contains domain information (the package
type has a different meaning in different domains). If the separator value is configured to the default
value, configure the package names as follows:
[SOAP.Policy.Package]
This configuration means that if the SOAP LEG received a query reply with the value 'gold' under the
label “TYPE”, and the value 'domain1' was passed to the SOAP LEG by the SM core under the label
“DOMAIN”, the package ID that will be associated to the subscriber in the SM will have the value 11.
[SOAP.Policy Logging]
log_missing_policy_name=false
log_all=false
log_default_policy_assignment=false
[SOAP.Policy.Package]
policy_name_format=TYPE,DOMAIN
name_seperator_value=_
# default package configuration
default_value=1
# Mapping table

34-4 OL-15752-01
CH A P T E R 35
Using the SOAP LEG CLU
This module describes the command-line utility (CLU) commands when the SOAP LEG software is
installed on the Subscriber Manager (SM).
Information About the p3soap Utility

The SOAP LEG contains its own CLU commands, called p3soap, for retrieving information and
statistics about the LEG.
The p3soap utility displays the LEG configuration and statistics. The command format is p3soap
<operation>[OPTIONS].
The following tables lists the p3soap operations.
Table 35-1 p3soap Operations
--show Displays all of SOAP LEG configuration and
status
--show-statistics Displays statistics for the SOAP LEG including:
failed queries, queries sent, queries received
--show-version Displays the SOAP LEG version number
--set-username Sets the username and password to enable secure
queries via the SOAP communication protocol
--reset-username Resets the username to cancel the secure queries

OL-15752-01 35-1
Chapter 35 Using the SOAP LEG CLU
Table 35-2 p3soap User Options
User Option Abbreviation Description

--username=USER-NAME -u Specifies the name of the user.
Used with the --set-username
and --reset-username
operations.
--password=USER-PASSWORD -P Specifies the password of the
user. Used with the
--set-username and
--reset-username operations.
Table 35-3 p3soap Miscellaneous Options

--remote=IP[:port] -r (Optional) Used with the
--set-username and
--reset-username operations to
configure secure queries on the
remote SM in High Availability
setups.
The Port option should be used if
the PRPC Server port on the
remove SM machine differs
from the default value (14374).
• Viewing the SOAP LEG Status, page 35-2

• Viewing the SOAP LEG Statistics, page 35-3
• Viewing the SOAP LEG Version, page 35-3
• Setting the username and password for Secure Requests, page 35-3
• Resetting the username and password for Secure Requests, page 35-3
Viewing the SOAP LEG Status

The following is an example of using the p3soap CLU with the show operation:
>p3soap --show
SOAP LEG:
=========
Active: true
Url: http://1.1.1.1:8080/services/ProvisioningServiceSoap.asmx
Username: N/A
Logging:
Log all queries: true
Log failed queries: true
>

35-2 OL-15752-01
Viewing the SOAP LEG Statistics

The following is an example of using the p3soap CLU with the show-statistics operation:
>p3soap --show-statistics
SOAP LEG statistics
===================
Failed queries: 1
Failed package association: 0
Queries in process: 0
Max-Concurrent queries: 0
>
Viewing the SOAP LEG Version

The following is an example of using the p3soap CLU with the show-version operation:
>p3soap --show-version
SOAP LEG 3.1.0 Build 176
>
Setting the username and password for Secure Requests

The following is an example of using the p3soap CLU with the set-username operation:
>p3soap --set-username --username=cisco --password=cisco
>
Resetting the username and password for Secure Requests

The following is an example of using the p3soap CLU with the reset-username operation:
>p3soap --reset-username
>

OL-15752-01 35-3

35-4 OL-15752-01
CH A P T E R 36
Cisco WSDL
Cisco WSDL
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://cisco.com/CiscoQuery"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://cisco.com/CiscoQuery"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified"
targetNamespace="http://cisco.com/CiscoQuery">
<s:complexType name="ArrayOfString">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded" name="string" nillable="true"
type="s:string" />
</s:sequence>
</s:complexType>
<s:element name="QuerySubscriberIn">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="subscriberId" type="s:string"/>
<s:element minOccurs="0" maxOccurs="1" name="mappings"
type="tns:ArrayOfString"/>
<s:element minOccurs="0" maxOccurs="1" name="keys" type="tns:ArrayOfString"/>
<s:element minOccurs="0" maxOccurs="1" name="values"
</s:sequence>
</s:complexType>
</s:element>
<s:element name="QuerySubscriberOut">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="subscriberId" type="s:string"/>

OL-15752-01 36-1
Chapter 36 Cisco WSDL
Cisco WSDL
<s:element minOccurs="0" maxOccurs="1" name="mappings"

<s:element minOccurs="0" maxOccurs="1" name="propertiesKeys"
<s:element minOccurs="0" maxOccurs="1" name="propertiesValues"
<s:element minOccurs="0" maxOccurs="1" name="keys" type="tns:ArrayOfString"/>
<s:element minOccurs="0" maxOccurs="1" name="values"
</s:sequence>
</s:complexType>
</s:element>
</s:schema>
</wsdl:types>
<wsdl:message name="QuerySubscriberSoapIn">
<wsdl:part name="parameters" element="tns:QuerySubscriberIn" />
</wsdl:message>
<wsdl:message name="QuerySubscriberSoapOut">
<wsdl:part name="parameters" element="tns:QuerySubscriberOut" />
</wsdl:message>
<wsdl:portType name="QueryServiceSoap">
<wsdl:operation name="QuerySubscriber">
<wsdl:input message="tns:QuerySubscriberSoapIn" />
<wsdl:output message="tns:QuerySubscriberSoapOut" />
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="QueryServiceSoap" type="tns:QueryServiceSoap">

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<wsdl:operation name="QuerySubscriber">
<soap:operation soapAction="http://cisco.com/CiscoQuery/QuerySubscriber"
style="document" />
<wsdl:input>
<soap:body use="literal" />
</wsdl:input>
<wsdl:output>
<soap:body use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="QueryService">
<documentation xmlns="http://schemas.xmlsoap.org/wsdl/">Queries subscribers
data</documentation>
<wsdl:port name="QueryServiceSoap" binding="tns:QueryServiceSoap">
<soap:address location="http://localhost:8080/axis/services/QueryServiceSoap" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

36-2 OL-15752-01

Cisco Scms SM Legs User Guide: Release 3.1.6 May 2008

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Cisco Scms SM Legs User Guide: Release 3.1.6 May 2008

Diunggah oleh

Hak Cipta:

Format Tersedia

Cisco SCMS SM LEGs User Guide

Customer Order Number: