Cisco SCMS SM LEGs User Guide · iii Cisco SCMS SM LEGs User Guide OL-15752-01 CONTENTS Preface xiii Document Revision History xiii Organization xiv Related Publications xvi Conventions

Cisco SCMS SM LEGs User GuideRelease 3.1.6 May 2008

Americas HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706 USAhttp://www.cisco.comTel: 408 526-4000

800 553-NETS (6387)Fax: 408 527-0883

Text Part Number: OL-15752-01

http://www.cisco.com

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, CCSI, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco Stackpower, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0903R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

Cisco SCMS SM LEGs User Guide © 2008 Cisco Systems, Inc. All rights reserved.

OL-15752-01

C O N T E N T S

Preface xiii

Document Revision History xiii

Organization xiv

Related Publications xvi

Conventions xvi

Obtaining Documentation and Submitting a Service Request xvii

C H A P T E R 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

iiiCisco SCMS SM LEGs User Guide

Contents

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

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

P A R T 1 CNR LEG

C H A P T E R 2 About the CNR LEG 2-1

The CNR LEG Module 2-1

C H A P T E R 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

ivCisco SCMS SM LEGs User Guide

OL-15752-01

Contents

C H A P T E R 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

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

C H A P T E R 5 CNR Log Messages 5-1

Log Messages 5-1

C H A P T E R 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

vCisco SCMS SM LEGs User Guide

OL-15752-01

Contents

P A R T 2 DHCP Lease Query LEG

C H A P T E R 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


C H A P T E R 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

C H A P T E R 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-8

Viewing the DHCP Lease Query LEG Statistics 9-8

Viewing the DHCP Lease Query LEG Version 9-8

C H A P T E R 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-2

Upgrading the DHCP Lease Query LEG 10-2

C H A P T E R 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-3

viCisco SCMS SM LEGs User Guide

OL-15752-01

Contents

C H A P T E R 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

P A R T 3 SCE-Sniffer DHCP LEG

C H A P T E R 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

C H A P T E R 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

C H A P T E R 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

C H A P T E R 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

viiCisco SCMS SM LEGs User Guide

OL-15752-01

Contents

P A R T 4 RADIUS Listener LEG

C H A P T E R 17 About the RADIUS Listener LEG 17-1

About the RADIUS Listener LEG 17-1

Topologies 17-2

C H A P T E R 18 Installing the RADIUS Listener LEG 18-1

Installing the RADIUS Listener LEG Software 18-1

Uninstalling the RADIUS Listener LEG 18-2

C H A P T E R 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-5

Regular Expression Processing versus RADIUS Listener Login Rate 19-6

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-9

Configuring Stripping of the Attribute Value Example using Regular Expression Rule 19-9

Mapping of RADIUS Attribute to Subscriber Policy 19-9

Extracting Data from a RADIUS Attribute 19-10

Validation Rules 19-11

Extracting Data from a RADIUS Attribute Example 19-11

Not Setting Any Policy to the Subscriber 19-12

Mapping of RADIUS Attribute to Subscriber IP Address 19-12

Configuring Subscriber IP Address Example 19-13

Configuring Subscriber IP Address over VPN Example 19-13

Configuring the NAS Devices 19-14

Configuring the NAS Devices: Example 19-14

C H A P T E R 20 Configuring the RADIUS Client 20-1

Configuring the RADIUS Client 20-1

viiiCisco SCMS SM LEGs User Guide

OL-15752-01

Contents

C H A P T E R 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

C H A P T E R 22 Domain Association Algorithm 22-1

Domain Association Algorithm 22-1

P A R T 5 SCE-Sniffer RADIUS LEG

C H A P T E R 23 About the SCE-Sniffer RADIUS LEG 23-1

Information About the SCE-Sniffer RADIUS LEG 23-1

RADIUS Integration Overview 23-2

C H A P T E R 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

C H A P T E R 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

ixCisco SCMS SM LEGs User Guide

OL-15752-01

Contents

C H A P T E R 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

C H A P T E R 27 Using the SCE-Sniffer RADIUS LEG CLU 27-1

Information About the SCE-Sniffer RADIUS LEG Utility 27-1

Viewing the SCE-Sniffer RADIUS LEG Status 27-2

Viewing the SCE-Sniffer RADIUS LEG Version 27-2

Viewing the SCE-Sniffer RADIUS LEG Statistics 27-2

P A R T 6 MPLS/VPN BGP LEG

C H A P T E R 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

C H A P T E R 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

C H A P T E R 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

xCisco SCMS SM LEGs User Guide

OL-15752-01

Contents

C H A P T E R 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

P A R T 7 SOAP LEG

C H A P T E R 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

Common Topologies 32-3

C H A P T E R 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

C H A P T E R 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

C H A P T E R 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

C H A P T E R 36 Cisco WSDL 36-1

Cisco WSDL 36-1

xiCisco SCMS SM LEGs User Guide

OL-15752-01

Contents

xiiCisco SCMS SM LEGs User Guide

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 HistoryThe Document Revision History below records changes to this document.

RevisionCisco Service Control Release and Date Change Summary

OL-15752-01 3.1.6 May, 2008

• First version of this document to consolidate all LEG documentation into a single guide.

• RADIUS Listener LEG changes:

– Updated the regular expression utility behavior. See Regular Expression Examples, page 19-5 and Regular Expression Processing versus RADIUS Listener Login Rate, page 19-6.

– Addition of performance option to p3radius command-line utility. See Information About the p3radius Utility, page 21-1.

xiiiCisco SCMS SM LEGs User Guide

OL-15752-01

Preface

OrganizationThis guide contains the following sections:

Chapter Description

Chapter 1, “Terms and Concepts” Describes the terms and concepts used in this SM LEGs guide.

Chapter 2, “About the CNR LEG” Describes the Subscriber Manager CNR LEG software module.

Chapter 3, “Installing the CNR LEG” Describes the CNR LEG installation procedures for both Widows and Solaris platforms. It also describes the uninstall procedure.

Chapter 4, “Configuring the CNR LEG and the SM”

Describes the configuration for the CNR LEG and the Subscriber Manager using the CNR LEG.

Chapter 5, “CNR Log Messages” Describes the log messages written to the CNR Log.

Chapter 6, “CNR LEG Functional Specification”

Describes the CNR LEG design, logging, tracing, and operations performed by the CNR LEG.

Chapter 7, “About the DHCP Lease Query LEG”

Describes the Subscriber Manager DHCP Lease 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.

Chapter 8, “Subscriber Manager Integration”

Describes the procedures for installing, uninstalling, and upgrading the software on the Subscriber Manager.

Chapter 9, “Subscriber Manager Integration - Configuration”

Describes the procedures for configuring and using the software on the Subscriber Manager. It also describes the command-line utility.

Chapter 10, “SCE Integration” Describes the procedures for installing, uninstalling, and upgrading the software on an SCE device.

Chapter 11, “SCE Integration - Configuration”

Describes the procedures for configuring and using the software on an SCE device. It also describes the CLI.

Chapter 12, “DHCP Forwarder Application”

Describes the DHCP Forwarder application, installation instructions, and adding and removing a resource.

Chapter 13, “About the SCE-Sniffer DHCP LEG”

Describes the Subscriber Manager SCE-Sniffer 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.

Chapter 14, “Installing the SCE-Sniffer DHCP LEG”

Describes the procedures for installing the software on the Subscriber Manager. It also describes uninstalling the software and upgrading procedures.

Chapter 15, “Configuring the SCE-Sniffer DHCP LEG”

Describes the configuration procedure for the SCE-Sniffer DHCP LEG on the SM and configuring the Package Association.

Chapter 16, “Using the SCE-Sniffer DHCP LEG CLU”

Provides a description of the command-line utility commands when the software is installed on the Subscriber Manager.

Chapter 17, “About the RADIUS Listener LEG”

Describes the Subscriber Manager RADIUS Listener LEG software module and the terms and concepts used in this guide.

xivCisco SCMS SM LEGs User Guide

OL-15752-01

Preface

Chapter 18, “Installing the RADIUS Listener LEG”

Describes the procedures for installing the software on the Subscriber Manager. It also describes uninstalling the software and upgrading procedures.

Chapter 19, “Configuring the RADIUS Listener LEG”

Describes the configuration procedure for the RADIUS Listener LEG.

Chapter 20, “Configuring the RADIUS Client”

Describes the configuration procedure for the RADIUS Client.

Chapter 21, “Using the RADIUS Listener LEG CLU”


Chapter 22, “Domain Association Algorithm”

Describes the algorithm used for deciding the subscriber domain to which a subscriber should be logged on.

Chapter 23, “About the SCE-Sniffer RADIUS LEG”

Describes the SCE-Sniffer RADIUS LEG software module, and terms and concepts.

Chapter 24, “SCE-Sniffer RADIUS LEG Functionality”

Provides a description of SCE-Sniffer RADIUS LEG transactions for login and logout operations.

Chapter 25, “Installing the SCE-Sniffer RADIUS LEG”

Describes the installation process for installing the SM SCE-Sniffer RADIUS LEG.

Chapter 26, “Configuring the SCE-Sniffer RADIUS LEG”

Provides the configuration instructions to configure the SCE-Sniffer RADIUS LEG.

Chapter 27, “Using the SCE-Sniffer RADIUS LEG CLU”

Describes the Command-Line Utilities to retrieve information and statistics about the LEG.

Chapter 28, “About the MPLS/VPN BGP LEG”

Describes the MPLS/VPN BGP LEG software module, and terms and concepts.

Chapter 29, “Installing the MPLS/VPN BGP LEG”

Describes the installation process for installing the SM MPLS/VPN BGP LEG.

Chapter 30, “Configuring the MPLS/VPN BGP LEG”

Provides the configuration instructions to configure the MPLS/VPN BGP LEG.

Chapter 31, “Using the MPLS/VPN BGP LEG CLU”

Describes the Command-Line Utility to control the operation of the MPLS/VPN BGP LEG and to retrieve information and statistics about the LEG.

Chapter 32, “About the SOAP LEG” Describes the SOAP LEG software module, and terms and concepts.

Chapter 33, “Installing the SOAP LEG”

Describes the installation process for installing the SOAP LEG.

Chapter 34, “Configuring the SOAP LEG”

Provides the configuration instructions to configure the SOAP LEG.

Chapter 35, “Using the SOAP LEG CLU”


Chapter 36, “Cisco WSDL” The Cisco WSDL.

Chapter Description

xvCisco SCMS SM LEGs User Guide

OL-15752-01

Preface

Related PublicationsUse 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

ConventionsThis document uses the following conventions:

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.

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.

xviCisco SCMS SM LEGs User Guide

OL-15752-01

http://www.cisco.com/en/US/docs/cable/serv_exch/serv_control/broadband_app/rel316/smug/smug.html

http://www.cisco.com/en/US/docs/cable/serv_exch/serv_control/broadband_app/rel316/scabbug/scabbug.html

Preface

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 RequestFor 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.

xviiCisco SCMS SM LEGs User Guide

OL-15752-01

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Preface

xviiiCisco SCMS SM LEGs User Guide

OL-15752-01

OL-15752-01

C H 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.

1-1Cisco SCMS SM LEGs User Guide


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.


OL-15752-01

http://www.cisco.com/en/US/docs/cable/serv_exch/serv_control/broadband_app/rel316/smug/Configuration_File_Options.html

http://www.cisco.com/en/US/products/ps6150/products_installation_and_configuration_guide_book09186a008084f9d2.html

http://www.cisco.com/en/US/products/ps6150/products_installation_and_configuration_guide_book09186a008084f9d2.html

http://www.cisco.com/en/US/products/ps6151/products_installation_and_configuration_guide_book09186a0080841938.html

Chapter 1 Terms and Concepts 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

http://www.cisco.com/en/US/docs/cable/serv_exch/serv_control/broadband_app/rel316/smug/Configuration_File_Options.html

http://www.cisco.com/en/US/docs/cable/serv_exch/serv_control/broadband_app/rel316/c_api/c_api.html

Chapter 1 Terms and Concepts 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.


OL-15752-01

http://www.cisco.com/en/US/docs/cable/serv_exch/serv_control/broadband_app/rel316/smug/CPE_as_Subscriber_in_Cable_Environment.html




Chapter 1 Terms and Concepts 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

http://www.ietf.org/rfc/rfc4388.txt



Chapter 1 Terms and Concepts 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").


OL-15752-01

Chapter 1 Terms and Concepts 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.

MPLS/VPN BGP Concepts • 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


Chapter 1 Terms and Concepts MPLS/VPN BGP Concepts

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.


OL-15752-01

Chapter 1 Terms and Concepts 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

Chapter 1 Terms and Concepts SOAP Concepts


OL-15752-01

P A R T 1

CNR LEG

OL-15752-01

C H 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.


Chapter 2 About the CNR LEG The CNR LEG Module


OL-15752-01

OL-15752-01

C H 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


Chapter 3 Installing the CNR LEG Installing the CNR LEG on Windows

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

cnrleg.cfg Sample configuration file

solaris

libcnrleg.so Solaris distribution in a single library file

winnt

asn1ber.dll

asn1rt.dll

cnrleg.dll

Table 3-1 File layout of CNR LEG distribution package (continued)


1. Any sequence number can be used for this command.


OL-15752-01

Chapter 3 Installing the CNR LEG Installing the CNR LEG on Solaris

nrcmd>extension smlegext create dex cnrleg.dll cnrLegPostPacketDecode 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 nrcmd>server DHCP reload





OL-15752-01

Chapter 3 Installing the CNR LEG Uninstalling the CNR LEG

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.

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 nrcmd>server DHCP reload

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).


OL-15752-01

OL-15752-01

C H 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.


http://www.cisco.com/en/US/docs/cable/serv_exch/serv_control/broadband_app/rel315/smug315/Configuration_File_Options.html

Chapter 4 Configuring the CNR LEG and the SM Information About Configuring the CNR LEG

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

The following example is a portion of a sample CNR configuration file showing how to configure the 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


OL-15752-01

Chapter 4 Configuring the CNR LEG and the SM Information About Configuring the CNR LEG

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

The following example is a portion of a sample CNR configuration file showing how to configure the 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

Chapter 4 Configuring the CNR LEG and the SM Information About Configuring the Subscriber Manager

Lease Time Option Example

The following example is a portion of a sample CNR configuration file showing how to configure the lease time option:

lease_time_option=51

Information About Configuring the Subscriber Manager 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


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


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 following example is a portion of a sample p3sm.cfg configuration file showing how to configure 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


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 following example is a portion of a sample p3sm.cfg configuration file showing how to configure 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


[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


OL-15752-01

OL-15752-01

C H 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>"


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> - probably buffer overflow" – logged in CPE as subscriber mode

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> - probably buffer overflow" – logged in CPE as subscriber mode

• "CNR LEG: CPE Logout - failed to logout CPE <name>, IP <IP address> - probably buffer overflow" – logged in CPE as subscriber mode


OL-15752-01

OL-15752-01

C H 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.


Chapter 6 CNR LEG Functional Specification Logging and Tracing

Figure 6-1 CNR LEG High Level Design

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 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

CNR LEG

Cablesupportmodule

PRPCServer

Networktask

Messagequeue

Non-blocking C++ API

loginCable logoutCable

init-entryExtension Point

post-packet-encode

post-send-packet

SM Corefunctionality

1570

52

Network

SM


OL-15752-01

Chapter 6 CNR LEG Functional Specification Extensions Point Operation

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

Chapter 6 CNR LEG Functional Specification Extensions Point Operation


OL-15752-01

P A R T 2

DHCP Lease Query LEG

OL-15752-01

C H 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:


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

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

Traffic (1)

Pull (3)Login (5)

LeaseQuery (4)

DHCPServer

DHCPLeaseQueryLEG

SM

SCE

1570

54

PullRequest(2)

PullResponse

(6)

Traffic (1)

LeaseQuery (3)

DHCPServer

DHCPLeaseQueryLEG

SCE

1570

55

PullRequest(2)

PullResponse

(4)


OL-15752-01

Chapter 7 About the DHCP Lease Query LEG 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.

Information About DHCP Lease Query LEG Functionality • 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.


OL-15752-01



The following is a detailed description of the attributes extracted from the DHCP Lease Query transaction:

• 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 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.


OL-15752-01


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:

Note The directory to which the distribution is extracted is referred to as pkg-ext-dir.

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

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


OL-15752-01



OL-15752-01

OL-15752-01

C H 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


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.


OL-15752-01

http://www.cisco.com/en/US/docs/cable/serv_exch/serv_control/broadband_app/rel316/smug/Installation_and_Upgrading.html

Chapter 8 Subscriber Manager Integration Upgrading the DHCP Lease Query LEG

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

Step 6 Load the new configuration of the SM by running the p3sm CLU

>p3sm --load-config


OL-15752-01

Chapter 8 Subscriber Manager Integration Upgrading the DHCP Lease Query LEG


OL-15752-01

OL-15752-01

C H 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.


Chapter 9 Subscriber Manager Integration - Configuration Information About Configuring the DHCP Lease Query LEG

• 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.



OL-15752-01


• log_all_queries

Controls log messages regarding each query sent and any reply received.

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


OL-15752-01


[DHCP-Lease-Query-Ids] lease_query=13 lease_active=16

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.



OL-15752-01


• 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 '_'.

• 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.


OL-15752-01


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.

• 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.

Possible values for this parameter are binary (a binary string that is converted to an ASCII 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.gold_domain2=12 mapping_table.silver_domain1=13 mapping_table.silver_domain2=14

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] options_order_for_policy_name=43:102,43:101 name_separator_value=_ use_default=true default_policy=1 policy_property_name=packageId allow_login_with_no_policy=false


OL-15752-01


log_all=false log_default_assignment=false mapping_table.gold_domain1=11 mapping_table.gold_domain2=12 mapping_table.silver_domain1=13 mapping_table.silver_domain2=14 [Additional Data] label_options=82:1 label_keys=PORT_ID label_options_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 and default Virtual-Link to be assigned to all the subscribers, as shown in the following example:

[DHCP.Policy.Package] policy_property_name=packageId allow_login_with_no_policy=false use_default=true default_policy=1 [DHCP.Policy.VirtualLinkDownstream] policy_property_name=downVlinkId allow_login_with_no_policy=false use_default=true default_policy=0 [DHCP.Policy.VirtualLinkUpstream] policy_property_name=upVlinkId allow_login_with_no_policy=false 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


OL-15752-01


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

• 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:

>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 Command terminated successfully >

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 >


OL-15752-01

OL-15752-01

C H 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-2

• 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.


Chapter 10 SCE Integration Uninstalling the DHCP Lease Query LEG from the SCE Device

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.

Run the following CLI on the SCE device.

SCE2000#>configure SCE2000(config)#>interface LineCard 0 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.

Upgrading the DHCP Lease Query LEG 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)#>interface LineCard 0 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)#>interface LineCard 0 SCE2000(config if)#>pqi install file LEG-PQI


OL-15752-01

http://www.cisco.com/en/US/docs/cable/serv_exch/serv_control/broadband_app/rel316/swcfg/Operations.html

Chapter 10 SCE Integration Upgrading the DHCP Lease Query LEG

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.


OL-15752-01

Chapter 10 SCE Integration Upgrading the DHCP Lease Query LEG


OL-15752-01

OL-15752-01

C H 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-3

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


Chapter 11 SCE Integration - Configuration Information About the DHCP Lease Query LEG CLI

To set the session_timeout variable to the default value:

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


OL-15752-01


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:

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



OL-15752-01

OL-15752-01

C H 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:

#/etc/init.d/p3dhcpforwarder start


Chapter 12 DHCP Forwarder Application Uninstalling the DHCP Forwarder

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.


OL-15752-01

Chapter 12 DHCP Forwarder Application DHCP Forwarder VCS Agent

Step 3 Note the path and arguments of the DHCP Forwarder.

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

Chapter 12 DHCP Forwarder Application DHCP Forwarder VCS Agent

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


OL-15752-01

P A R T 3

SCE-Sniffer DHCP LEG

OL-15752-01

C H 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:


Chapter 13 About the SCE-Sniffer DHCP LEG Information About SCE-Sniffer DHCP LEG Functionality

Figure 13-1 SCE-Sniffer DHCP LEG Operation

Information About SCE-Sniffer DHCP LEG Functionality 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.

Traffic (1)

LoginLogout (3)

SCE-SnifferDHCPLEG

SM

SCE

1570

81

RDR(2)


OL-15752-01


The chain of decisions regarding the subscriber-ID is as follows:

a. Use the configured DHCP option as the subscriber-ID if it exists.

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 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



OL-15752-01

OL-15752-01

C H 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




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>configureSCE2000(config)>RDR-formatter destination SM-IP port port category number 3 priority 100SCE2000(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>configureSCE2000(config)>no RDR-formatter destination SM-IP port portSCE2000(config)>exit

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.


OL-15752-01

Chapter 14 Installing the SCE-Sniffer DHCP LEG Upgrading the SCE-Sniffer DHCP LEG

Step 1 Backup the configuration files of the SCE-Sniffer DHCP LEG.


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


Chapter 14 Installing the SCE-Sniffer DHCP LEG Upgrading the SCE-Sniffer DHCP LEG


OL-15752-01

OL-15752-01

C H 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.



Chapter 15 Configuring the SCE-Sniffer DHCP LEG Information About Configuring the SCE-Sniffer DHCP LEG

• log_all

Defines whether the SM should add all messages, including successful logins and logouts, to the user log.


• 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


OL-15752-01


[Sniffer] packet_types=DHCPACK [Subscriber ID] 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.


OL-15752-01


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.



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.

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



• 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.


OL-15752-01


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.


• 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.

Possible values for this parameter are binary (a binary string that is converted to an ASCII 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.gold_domain2=12 mapping_table.silver_domain1=13 mapping_table.silver_domain2=14

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


[DHCP.Policy.Package] options_order_for_policy_name=43:102,43:101 name_separator_value=_ use_default=true default_policy=1 policy_property_name=packageId allow_login_with_no_policy=false log_all=false


OL-15752-01


log_default_assignment=false mapping_table.gold_domain1=11 mapping_table.gold_domain2=12 mapping_table.silver_domain1=13 mapping_table.silver_domain2=14 [Additional Data] 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:

[DHCP.Policy.Package] policy_property_name=packageId allow_login_with_no_policy=false use_default=true default_policy=1 [DHCP.Policy.VirtualLinkDownstream] policy_property_name=downVlinkId allow_login_with_no_policy=false use_default=true default_policy=0 [DHCP.Policy.VirtualLinkUpstream] policy_property_name=upVlinkId allow_login_with_no_policy=false use_default=true default_policy=0

All other configuration parameters should not be set.


OL-15752-01

OL-15752-01

C H 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.

• 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

Table 16-1 p3dhcpsniff Operations

Operation Description--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

--help Displays a list of available operations and arguments, with a short explanation of their meanings.


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 Command terminated successfully >

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 Command terminated successfully >

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 >


OL-15752-01

P A R T 4

RADIUS Listener LEG

OL-15752-01

C H 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.


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

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

1571

12

RADIUSServer/Proxy

SCE

TrafficLinks

ControlLinks

NAS / GGSN

SCE

Edge Router

NAS / GGSN

RADIUSListener

Internet

1571

13

RADIUSServer/Proxy

SCE

TrafficLinks

RADIUSAccounting

ControlLinks

NAS / GGSN

SCE

Edge Router

NAS / GGSN

RADIUSListener

Internet


OL-15752-01

OL-15752-01

C H 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.


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


OL-15752-01

OL-15752-01

C H 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-14

Configuring the General Settings

[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.


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

Information About the Regular Expression Utility 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-5

• Regular Expression Processing versus RADIUS Listener Login Rate, page 19-6

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)


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


– (?#...) 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.


OL-15752-01


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. [email protected]), define the following manipulation rule: (.*)@.*

• In order to remove the “name” prefix from a given name (e.g. [email protected]), 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 [email protected]), 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


OL-15752-01

Chapter 19 Configuring the RADIUS Listener LEG Configuring RADIUS Attributes Mapping

Regular Expression Processing versus RADIUS Listener Login RateUsing 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.

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.

Configuring RADIUS Attributes Mapping • 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-12

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.


OL-15752-01


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

• 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.


OL-15752-01


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.

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 fields=user_name,vpn # 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 # the type of the attribute (type "integer" or "string") radius_attribute_type = integer


OL-15752-01


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:

[Radius.Subscriber ID] # Field name fields=user_name [Radius.Field.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) # the type of the attribute (type "integer" or "string") radius_attribute_type = string

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:

[Radius.Subscriber ID] # Field name fields=user_name # Field manipulation field_manipulation.user_name=(.*)@.* [Radius.Field.user_name] # RADIUS protocol attribute number radius_attribute=1 # the type of the attribute (type "integer" or "string") radius_attribute_type = string

The above configuration applied on ‘[email protected]’ 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


OL-15752-01


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.

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.user_name=(.*)@.* 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


OL-15752-01


For each field defined by the fields parameter, you must also define a [Radius.Field.<field name>] section with the following parameters:







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 fields=user_name,vpn # Field separator field_separator=user_name@vpn # Field manipulation field_manipulation.user_name=(.*)@.* # Mapping table mapping_table..*@.*=1 mapping_table.^$=2 mapping_table..*=3 [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. # use the following format for VSAs: 26 vendor-id;sub-attribute) # for example: 26(9;1) radius_attribute = 26(9;1) # the type of the attribute (type "integer" or "string") radius_attribute_type = string


OL-15752-01


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.

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.


OL-15752-01


• 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>] section with the following parameters:







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 protocol attribute number radius_attribute=8 # the type of the attribute (type "integer" or "string") # if type is string a mapping table must be supplied # below. # (no default) radius_attribute_type=integer

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 protocol attribute number radius_attribute = 8 # the type of the attribute (type "integer" or "string") 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)


OL-15752-01

Chapter 19 Configuring the RADIUS Listener LEG Configuring the NAS Devices

radius_attribute = 26(9;1) # the type of the attribute (type "integer" or "string") radius_attribute_type = integer

Configuring the NAS Devices 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.

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


OL-15752-01

OL-15752-01

C H A P T E R 20
Configuring the RADIUS Client
This module describes the configuration procedure for a RADIUS Client.

Configuring the 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-12.

• (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-12.

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.


Chapter 20 Configuring the RADIUS Client Configuring the RADIUS Client


OL-15752-01

OL-15752-01

C H 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

Operation Description--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.


Chapter 21 Using the RADIUS Listener LEG CLU Information About the p3radius Utility

--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 exp rule]

Tests the validity of regular 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.

Table 21-1 p3radius Operations (continued)



OL-15752-01


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

--file=configuration_file name --fields=fieldname=fieldValue [ ,fieldname=fieldValue ] --section=section name

-f configuration_file name --fields=fieldname=fieldValue [ ,fieldname=fieldValue ] --section=section name

Tests the new/updated configuration file.

The tests are done by providing 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.

Table 21-2 p3radius Options (continued)

Option Abbreviation Description


OL-15752-01


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 -------------------------- Command terminated successfully >

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 Command terminated successfully >

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: .*


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@ Command terminated successfully >

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=(.*)@.*,.*@(.*) [email protected] --performance Pattern: '(.*)@.*'; String to reduce: '[email protected]'; Reduction result: 'user' Regular Expression operation time is 0.112 ms Pattern: '.*@(.*)'; String to reduce: '[email protected]'; Reduction result: 'cisco.com' Regular Expression operation time is 0.061 ms Command terminated successfully >

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 [email protected] --performance Pattern: 'ûser$'; String to match: '[email protected]'; Matching not found Regular Expression operation time is 0.0 ms. Pattern: 'user'; String to match: '[email protected]'; Match found Regular Expression operation time is 0.045 ms. Pattern: 'users'; String to match: '[email protected]'; Matching not found Regular Expression operation time is 0.045 ms. Command terminated successfully >


OL-15752-01



OL-15752-01

OL-15752-01

C H 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.

Domain Association Algorithm 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

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.

1571

07

RADIUSServer/Proxy

SCE

TrafficLinks

ControlLinks

NAS 1

SCE

Edge Router

NAS 2

RADIUSListener

Internet


Chapter 22 Domain Association Algorithm 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.


OL-15752-01

P A R T 5

SCE-Sniffer RADIUS LEG

OL-15752-01

C H 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

Traffic (1)

LoginLogout (3)

SCE-Sniffer

RADIUSLEG

SM

SCE

1570

82

RDR(2)


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.


OL-15752-01

OL-15752-01

C H 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.


Chapter 24 SCE-Sniffer RADIUS LEG Functionality Information About RADIUS Attributes

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.


OL-15752-01

Chapter 24 SCE-Sniffer RADIUS LEG Functionality Information About RADIUS Attributes

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

Chapter 24 SCE-Sniffer RADIUS LEG Functionality 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.

Information About RADIUS Packets 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.


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



OL-15752-01

OL-15752-01

C H 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.



Chapter 25 Installing the SCE-Sniffer RADIUS LEG Uninstalling the SCE-Sniffer RADIUS LEG

Step 3 Load the configuration file 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 Command-Line Interface (CLI) in the SCE to add the LEG as a category 3 RDR destination:

SCE2000>configureSCE2000(config)>RDR-formatter destination SM-IP port port category number 3 priority 100SCE2000(config)>exit

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>configureSCE2000(config)>no RDR-formatter destination SM-IP port portSCE2000(config)>exit

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.


OL-15752-01

Chapter 25 Installing the SCE-Sniffer RADIUS LEG Upgrading the SCE-Sniffer RADIUS LEG

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 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


Chapter 25 Installing the SCE-Sniffer RADIUS LEG Upgrading the SCE-Sniffer RADIUS LEG


OL-15752-01

OL-15752-01

C H 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

Configuring the General Settings 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.



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.


OL-15752-01

Chapter 26 Configuring the SCE-Sniffer RADIUS LEG 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

Chapter 26 Configuring the SCE-Sniffer RADIUS LEG Information About Configuring the Policy Settings

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.



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



OL-15752-01

OL-15752-01

C H 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.

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

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

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

Table 27-1 p3radiussniff Operations

Operation Description--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

--help Displays a list of available operations and arguments with a short explanation of their meanings.


Chapter 27 Using the SCE-Sniffer RADIUS LEG CLU Information About the SCE-Sniffer RADIUS LEG Utility

Viewing the SCE-Sniffer RADIUS LEG Status The following example illustrates the p3radiussniff CLU using the show operation:

>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 Command terminated successfully >

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 Command terminated successfully >

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 logins: 6 Successful logouts: 6 Failed logins: 0 Failed logout: 0 Command terminated successfully >


OL-15752-01

P A R T 6

MPLS/VPN BGP LEG

OL-15752-01

C H 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.


Chapter 28 About the MPLS/VPN BGP LEG MPLS/VPN BGP LEG Overview

Figure 28-1 illustrates the MPLS/VPN topology:

Figure 28-1 MPLS/VPN Topology

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.

MPLS/VPN BGP LEG Overview 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.

1570

96

VPN ASite 2

10.0.2.x

CE

VPN BSite 2

10.0.2.x

VPN ASite 1

10.0.1.x

VPN BSite 1

10.0.1.x

CE

CE

PPE

P

PE

CE

Service Provider'sMPLS core


OL-15752-01


Figure 28-2 illustrates the MPLS/VPN BGP LEG solution:

Figure 28-2 MPLS/VPN BGP LEG Solution

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.

SM BGP LEG

PEPEPEPE

SCESCESCESCE

add_route

BGP

PRPC

del_route

PRPC

UNIX Machine

1570

51


OL-15752-01


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 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.


OL-15752-01




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.

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



OL-15752-01

OL-15752-01

C H 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


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


OL-15752-01

Chapter 29 Installing the MPLS/VPN BGP LEG Removing a VCS Resource from the BGP LEG

Step 6 Click OK.

The following figure shows the Add Resource window:

Figure 29-1 Add VCS Resource Window

Note The arguments line might seem shorter than the actual full argument value, which is perfectly acceptable.

Removing a VCS Resource from the BGP LEG

Step 1 Right-click the BGP LEG resource icon you want to remove.

Step 2 From the drop-down list, choose Delete.


OL-15752-01

Chapter 29 Installing the MPLS/VPN BGP LEG Removing a VCS Resource from the BGP LEG

Figure 29-2 Removing a VCS Resource

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.


OL-15752-01

OL-15752-01

C H 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.


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.

Configuration File Example 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.


OL-15752-01


OL-15752-01

C H 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

Operation Description--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.


Chapter 31 Using the MPLS/VPN BGP LEG CLU Information About the MPLS/VPN BGP LEG CLU

BGP LEG Status The following is an example of the p3bgp command-line utility using the status operation:

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

--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

Table 31-1 p3bgp Operations (continued)


ID Peer IP PE NameUpdates recv Notify recv

K.Alive sent

K.Alive recv Hold Time

1 1.2.3.4 PE101 150 0 58 57 157

2 1.2.3.5 PE102 183 0 34 33 77


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



OL-15752-01

P A R T 7

SOAP LEG

OL-15752-01

C H 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


Chapter 32 About the SOAP LEG Information 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 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.


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

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).

2100

83

DHCP snifferLEG

SM

SOAP LEG

SMCORE

SOAPserver

1. Login

2. handleSubscriber

4. Login

3. Query subscriber

1. Login

2. handleSubscriber

4. Login

3. Query subscriber


OL-15752-01


The following figure shows the topology with the DHCP Sniffer LEG:

Figure 32-2 SOAP LEG Topology with DHCP Sniffer LEG

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).

2100

81

1. DHCP traffic

2. DHCP RDRs

DHCP snifferLEG

SM

SOAP LEG

SCECMTSDHCPserver

SMCORE

SOAPserver

3. Login

4. handleSubscriber

6. Login

5. Query subscriber

3. Login

4. handleSubscriber

6. Login

5. Query subscriber


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

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).

2100

82

4. Querysubscriber

3. handlesubscriber

SMCORE

SM

SOAP LEG

Lease query LEG

SCE

SOAPserver

DHCPserver

1. unknown traffic1. unknown traffic

7. Query subscriber

6. handlesubscriber

5. Login

8. Login

2. pull

7. Query subscriber

6. handlesubscriber

3. handlesubscriber

5. Login

8. Login

4. Querysubscriber

2. pull


OL-15752-01



OL-15752-01

OL-15752-01

C H 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.



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


OL-15752-01


OL-15752-01

C H 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.


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.

Configuration File Example 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

Information about Configuring the Package Association


• 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.


OL-15752-01


The [SOAP.Policy.Package] section of the configuration file contains the following parameters:

• 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.

Note The policy_property_name parameter is case sensitive and must be written exactly as defined by the 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.




OL-15752-01


• log_all




Note Set the log_all parameter to true only when troubleshooting.

• log_default_policy_assignment

Defines whether to write a user-log message for every assignment of the default value (as defined 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] mapping_table.gold_domain1=11 mapping_table.gold_domain2=12 mapping_table.silver_domain1=13 mapping_table.silver_domain2=14

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=_ policy_property_name=packageId # default package configuration default_value=1 allow_login_with_no_policy=false # Mapping table mapping_table.gold_domain1=11 mapping_table.gold_domain2=12 mapping_table.silver_domain1=13 mapping_table.silver_domain2=14


OL-15752-01

OL-15752-01

C H 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

Operation Description--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


Chapter 35 Using the SOAP LEG CLU Information About the p3soap Utility

• 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 Command terminated successfully >

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

Option Abbreviation Description--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).


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 =================== Successful logins: 3 Failed queries: 1 Failed package association: 0 Queries in process: 0 Max-Concurrent queries: 0 Command terminated successfully >

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 Command terminated successfully >

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 Command terminated successfully >

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 Command terminated successfully >


OL-15752-01



OL-15752-01

OL-15752-01

C H 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" type="tns:ArrayOfString"/> </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"/> <s:element minOccurs="0" maxOccurs="1" name="mappings" type="tns:ArrayOfString"/> <s:element minOccurs="0" maxOccurs="1" name="propertiesKeys" type="tns:ArrayOfString"/>


Chapter 36 Cisco WSDL Cisco WSDL

<s:element minOccurs="0" maxOccurs="1" name="propertiesValues" type="tns:ArrayOfString"/> <s:element minOccurs="0" maxOccurs="1" name="keys" type="tns:ArrayOfString"/> <s:element minOccurs="0" maxOccurs="1" name="values" type="tns:ArrayOfString"/> </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>


OL-15752-01

Documents

Cisco SCMS SM LEGs User Guide · iii Cisco SCMS SM LEGs User Guide OL-15752-01 CONTENTS Preface xiii Document Revision History xiii Organization xiv Related Publications xvi Conventions