Day One: SBR Change of Authorization (CoA) and the MX Series · In this book you’ll see how Juniper’s subscriber management solution (the MX Series and Steel Belted RADIUS) can

Junos® Networking technologies

Build a MX subscriber management

solution along with RADiuS authen-

tication, authorization, accounting,

and Change of Authorization (CoA)

using Juniper’s Steel-Belted Radius.

By John Rolfe

DAy ONe: SBR CHANge OF AUTHORIzATION (CoA) AND THe MX SeRIeS

Juniper Networks Books are singularly focused on network productivity and efficiency. Peruse the complete library at www.juniper.net/books.

Published by Juniper Networks Books

DAY ONE: SBR ChANgE Of AuthORizAtiON (CoA) AND thE MX SERiES

This book describes the steps needed to build a MX subscriber management solu-tion along with RADIUS authentication, authorization, accounting, and change of au-thorization using Juniper’s Steel Belted Radius (SBR). The author walks you through the process, step-by-step, setting up a dynamic profile on the MX, setting firewall/policers to the profile via RADIUS, and then changing those values via RADIUS CoA. Then John Rolfe guides you through the required XML envelopes, setting up a web server, and implementing a self-service portal to invoke the CoA, utilizing an HTML Web page with a PHP script built on XAMPP (from Apache Friends), which includes the Apache web server, PHP, Perl, and other components.

Day One: SBR Change of Authorization (CoA) and the MX Series is meant for the lab, for a day exploring the basic tenets of software defined networks (SDN) by using the MX Series, Junos, and SBR to create a CoA solution.

Juniper CoA solutions can enable a number of network use cases, from automating service provisioning, to credit card authorization portals, to self-service portals for network and subscriber provisioning. Learn the basics here, in a day, and you’ll be able to explore these and other use cases for your own network needs.

it’S DAY ONE AND YOu hAVE A JOB tO DO, SO LEARN hOW tO:

n Handle DHCP subscribers using MX DHCP local server. n Configure IP demux on the subscriber interface. n Create QoS configuration templates for deployment. n Build dynamic profiles using the firewall filter/policer for QOS. n Use SBR Carrier using Session Control Module (SCM) for CoA. n Utilize SBR Carrier XML over HTTPS API. n Perform PHP scripting to implement the HTTPS XML post. n Build a basic Apache web server page.

ISBN 978-1936779635

9 781936 779635

5 1 2 0 0

07100164

Day One: SBR Change of Authorization (CoA)

and the MX Series

By John Rolfe

Junos® Networking Technologies

Chapter 1 : MX Dynamic Subscriber Management . . . . . . . . . . . . . . . . . . . . . . 9

Chapter 2 : Setting Up the MX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

Chapter 3 : Adding SBR to the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapter 4: Basic CoA Setup Using SBR GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

Chapter 5: Simple Web Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

© 2013 by Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, Junos, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. Junose is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.

Published by Juniper Networks BooksAuthor: John RolfeTechnical Reviewers: Hartmut Schroeder, Wayne Brassem, Jon Canchola, and Devasena Morrissette Editor in Chief: Patrick AmesCopyeditor and Proofer: Nancy KoerbelJ-Net Community Manager: Julie Wider

About the AuthorJohn Rolfe has over 30 years of experience in the networking industry. He is presently a consulting system engineer in the Technologies and Solution group at Juniper Networks, focusing on identity and policy management as well as network management systems. Prior to Juniper Networks, he worked in the VOIP industry with session border controllers at NexTone. Prior to that, he spent seven years in the semiconductor industry, primarily in Network Processing silicon with Agere.

Author’s AcknowledgmentsThank you to everyone involved in making this book, especially my family.

ISBN: 978-1-936779-63-5 (print)Printed in the USA by Vervante Corporation.

ISBN: 978-1-936779-64-2 (ebook)

Version History: v1 March 2013 2 3 4 5 6 7 8 9 10 #7100164-en

This book is available in a variety of formats at: http://www.juniper.net/dayone. Send your suggestions, comments, and critiques by email to [email protected].

iv

http://www.juniper.net/dayone


Welcome to Day One

This book is part of a growing library of Day One books, produced and published by Juniper Networks Books.

Day One books were conceived to help you get just the information that you need on day one. The series covers Junos OS and Juniper Networks networking essentials with straightforward explanations, step-by-step instructions, and practical examples that are easy to follow.

The Day One library also includes a slightly larger and longer suite of This Week books, whose concepts and test bed examples are more similar to a weeklong seminar.

You can obtain either series, in multiple formats:

� Download a free PDF edition at http://www.juniper.net/dayone.

� Get the ebook edition for iPhones and iPads from the iTunes Store. Search for Juniper Networks Books.

� Get the ebook edition for any device that runs the Kindle app (Android, Kindle, iPad, PC, or Mac) by opening your device's Kindle app and going to the Kindle Store. Search for Juniper Networks Books.

� Purchase the paper edition at either Vervante Corporation (www.vervante.com) or Amazon (amazon.com) for between $12-$28, depending on page length.

� Note that Nook, iPad, and various Android apps can also view PDF files.

� If your device or ebook app uses .epub files, but isn't an Apple product, open iTunes and download the .epub file from the iTunes Store. You can now drag and drop the file out of iTunes onto your desktop and sync with your .epub device.

v


http://www.vervante.com

http://www.vervante.com

http://www.amazon.com

vi

What You Need to Know Before Reading This Book

Before reading this book, you should be familiar with the basic administrative functions of the Junos operating system, including the ability to work with operational commands and to read, understand, and change Junos configurations. There are several books in the Day One library on exploring and learning Junos, at www.juniper.net/dayone.

This book also makes a few assumptions about you, the reader:

� You are versed in authentication principles.

� You have operational experience with the MX Series.

� You have basic understanding of Linux and editing text files in Linux.

� You have a good understanding of Junos and know enough about XML to, well, get by.

After Reading This Book, You’ll Be Able To:

� Handle DHCP subscribers using MX DHCP local server.

� Configure IP demux on the subscriber interface.

� Create QoS configuration templates for deployment.

� Build dynamic profiles using the firewall filter/policer for QOS.

� Use SBR Carrier using Session Control Module (SCM) for CoA.

� Utilize SBR Carrier XML over HTTPS API.

� Perform PHP scripting to implement the HTTPS XML post.

� Build a basic Apache web server page.



vii

About Change of Authorization

This book describes the steps needed to deploy an MX subscriber management solution along with RADIUS authentication, authoriza-tion, accounting, and Change of Authorization using Juniper’s Steel Belted Radius (SBR). The book walks you through a basic dynamic profile on the MX step-by-step, setting firewall/policers to the profile via RADIUS, and then changing those values via RADIUS CoA. The final chapter guides you through the required XML envelopes, setting up a web server, and implementing a self-service portal to invoke the CoA. It utilizes an HTML Web page with a PHP script built on XAMPP (from Apache Friends), which includes the Apache web server along with PHP, Perl, and other components.

This Juniper Networks solution enables a number of network use cases, including:

� Automating service provisioning

� Self service portal for network and subscriber provisioning

� Captive portal services for delinquent accounts/terms and conditions

� Service provider Wi-Fi captive portal

� Credit card authenticating portals

� Content sources optimizing session (for example, pay per view video)

The configuration for all of these use cases goes beyond the scope of this book, so let’s concentrate our efforts on the self-service portal and get it done in a day. You can then explore the use cases that interest you or your network.

MORE? For VLAN models please see Day One: Dynamic Subscriber Manage-ment at http://www.juniper.net/dayone. This is also a good resource for Class of Services issues in Dynamic Subscriber Management.


viii

Chapter 1

MX Dynamic Subscriber Management

The Lab Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

The Basic Use Case and Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Change of Authorization (CoA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

10 DayOne:SBRChangeofAuthorization(CoA)andtheMXSeries

This chapter introduces you to RADIUS-based dynamic subscriber management on the MX series, along with the concepts of Junos variables ($junos) in the MX and how those concepts relate to RADIUS attributes. This chapter may seem like a recap of another Day One book - Day One: Dynamic Subscriber Management – but it includes an introduction to the concept of in-session changes (Change of Authorization, or CoA) and some of the use cases associated with it. In this book you’ll see how Juniper’s subscriber management solution (the MX Series and Steel Belted RADIUS) can be controlled by external web pages or systems invoking dynamic changes on the subscriber session. While this book focuses on dynamic changes on the firewall filter, any RADIUS controlled attribute could be used, depending on your use case. Which is kind of cool.

The remainder of the book then goes through the steps necessary to configure, test, and troubleshoot the required MX, SBR, and Apache systems to implement a self-service portal. There’s a logical progres-sion to the setup with the ultimate goal of portal-based CoA. The concepts you learn should allow you to execute proof of concept and lab testing scenarios for yourself, as well as getting a hands-on under-standing of what can be done to the subscriber’s connection param-eters via external systems.

The Lab Setup

Figure 1.1 shows the basic lab configuration used for this book. The leftmost device is simply a DHCP client, which happens to be a Windows PC with an Ethernet connection to the MX. This connection emulates our subscriber.

Also connected to the MX is another PC, running the Apache server software, that is also our SSH/Telnet client to the other systems. The SBR system in Figure 1.1 is a Centos Linux machine running SBR Carrier with the Session Control Module license (SCM).

NOTE The SBR server can be installed in a Centos Linux VM on the same PC running Apache – place it in bridged mode so it has its own IP address.

NOTE SBR needs to run on Red Hat Enterprise Server in production net-works, but Centos is binary compatible and freely available. SBR also runs in a SPARC Solaris environment.

The SCM license allows SBR to implement CoA to the MX, as well as being the authentication and authorization server for the subscriber on

Chapter1:MXDynamicSubscriberManagement 11

behalf of the MX. In the test lab for the book, there is also Internet connectivity off the MX, which permits us to go to speed test sites to confirm our dynamic changes to the session.

Figure 1.1 The Lab for this Book

In a Service Provider’s network, the subscribers will typically come in off of DSLAM’s, ONT’s, or WiFi hotspots, possibly through other aggregation devices, and ultimately to the MX via 1- or 10 Gig Ethernets. The MX in this capacity is a Broadband Remote Access Server (BRAS - old term), now more commonly referred to as a Broadband Network Gateway (BNG). The subscribers will usually come in via VLAN’s requiring another step in the MX configuration. This VLAN demux is described in Day One: Dynamic Subscriber Management but as far as understanding the configuration, it’s very similar.

The MX, acting as a BNG, will provide access to network services for the subscriber. The parameters for the network connection will be both statically set up in the MX, and dynamically applied by SBR. The dynamically applied parameters in this book will be the specifics on policing for each subscriber.

The Basic Use Case and Flow

The following ladder diagram and text explains the flows that happen as a subscriber comes active.


Figure 1.2 Ladder Diagram of a New Subscriber Connection

When a subscriber connection comes active, it issues a DHCP discov-ery, which is a Layer 3 broadcast. The MX is configured as a local DHCP server with Radius authorization, and as such, issues an access request to RADIUS. The access request has a user-name as the MAC-Address of the subscriber with a prefix and a password of Juniper. The password is configured statically in the MX and must be present in the access request to conform to the RADIUS RFC. This is typically referred to as authorization; since all users have the same password, it’s not technically authenticating anything, it’s simply authorizing the subscriber for a particular set of session attributes.

Upon receipt of the access request, SBR will look up the user-name and password in its subscriber database, and as long as the passwords

Chapter1:MXDynamicSubscriberManagement 13

match, will accept the request. The subscriber database will also contain a profile name, the profile name matches a list of attributes to be returned to the MX in the access accept message. These attributes are dynamically attached to the subscriber’s connection. In our use case, firewall filters are applied on the ingress and egress that police all traffic to 2Mbps. Firewall filters with policers at 5M and 10M are also defined and they will be the filters changed using CoA.

After SBR accepts the connection and returns the RADIUS attributes referencing the ingress and egress firewall filters, the MX finishes the DHCP process and applies the dynamic profile to the connection.

Change of Authorization (CoA)

Once a subscriber session has been authorized and the dynamic profile has been applied, the MX issues a RADIUS accounting start message. This message contains the two most important attributes used to identify the subscriber: the Accounting-Session-ID and the NAS-IP-Address (MX IP address). Any CoA message uses these two attributes to invoke the CoA. Since the Accounting-Session-ID is unique to the MX, the MX knows which session to change. Using the Accounting-Session-ID is a convention in CoA with the MX, while other device vendors may use different attributes, such as NAS-Port-ID.

SBR uses a current session table built from accounting starts and accounting interim messages, to store these session records. The current session table contains attributes from these messages such as Framed-IP-Address, User-Name (which in our lab is the MAC address with prefix), and other information relevant to the session. Having this information in real time allows external systems to invoke a CoA by issuing a simple HTTPS post of an XML envelope that would contain (as a pseudo example):

� action = change speed

� rate = 10M (Egress-Policy-Name attribute, or firewall filter name in the MX)

� Framed-IP-Address = 10.10.10.55

The rate = 10M would actually be a RADIUS attribute corresponding to a firewall filter name. It’s important to note that there are many attributes available for CoA in a Juniper MX, but this book is only using a couple of them. As you apply the techniques in this book to other use cases, be aware of multiple attributes available for CoA in a Juniper MX, as listed in Table 1.1.

A full description of the XML envelope setup is discussed in later chapters.


Table 1.1 Supported Juniper Networks Vendor-Specific Attributes (VSAs) for use with CoA

VSA Attribute

Ingress-Policy-Name Input policy name to apply to client interface.

Egress-Policy-Name Output policy name to apply to client interface

IGMP-Enable Enable or disable IGMP on a client interface

LI-Action Traffic mirroring action

Med-Dev- Handle Link to which traffic mirroring is applied

Service-Statistics Enable or disable statistics for the service

IGMP-Access-Group-Name Access list to use for the group filter

MP-Access-Source-Group-Name Access list to use for the source-group filter

MLD-Access-Group-Name Access list to use for the group filter

MLD-Access-Source-Group-Name Access list to use for the source-group filter

MLD-Version MLD protocol version

IGMP-Version IGMP protocol version

IGMP-Immediate-Leave IGMP immediate leave

MLD-Immediate-Leave MLD immediate leave

IPv6-Ingress-Policy-Name Input policy to apply to a user IPv6 interface

IPv6-Egress-Policy-Name Output policy to apply to a user IPv6 interface

CoS-Shaping-Pmt-Type CoS traffic shaping parameter type

Interface-Set-Name Interface set to apply to the dynamic profile

Service-Interim-Acct-Interval Amount of time between accounting interims for this service

CoS-Scheduler-Pmt-Type CoS scheduler parameter types

Chapter 2

Setting Up the MX

Configuring the MX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Licensing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Configuring the Loopback Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Configuring ge-2/2/0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Configuring the DHCP Local Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Configuring the Dynamic Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Checkpoint – Validating the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

Adding Firewall Filters to the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25


This chapter describes the basic setup for a DHCP client to obtain its IP address from the MX local DHCP server, as well as authorizing the connection via RADIUS (SBR). To keep the configuration simple, let’s use an IP demux connection, no VLANs, along with ingress and egress firewall filters (policers). The final step will be to configure the MX to authorize the connection from SBR and SBR to push the firewall filter names to the MX via RADIUS VSAs (Vendor Specific Attributes).

Configuring the MX

Figure 2.1 shows our simple DHCP client (PC in our case) connected to the MX. The MX has a local DHCP pool assigning addresses 10.10.10.50 through 10.10.10.60 via interface ge-2/0/0.

Figure 2.1 MX Configuration for DHCP Local Server

The steps needed to configure this basic setup are:

� Configure the loopback interface (using 10.10.10.149/32)

� Configure ge-2/2/0 to create dynamic IP Demux interfaces

� Configure DHCP local server

� Configure dynamic profile used by ge-2/2/0

Licensing Requirements

The MX comes with a 30-day trial license for 1K subscriber sessions, if this is not sufficient with the equipment in your lab, two licenses will be required.

� For chassis-based MX’s (the 240, 480, and 960), the SKU is S-SA-FP; for the MX80 family the SKU is S-MX80-SA-FP. These SKU’s are Feature Pack for Subscriber Access features.

Chapter2:SettingUptheMX 17

� The second license is for session scale. These are available in several increments; one example is S-SA-4K for 4K subscriber sessions. The licenses are incremental.

To install the licenses use the request system license add command. To view the installed licenses, use the show system license command:

root@Camlab> show system license License usage: Licenses Licenses Licenses Expiry Feature name used installed needed subscriber-accounting 1 1 0 permanent subscriber-authentication 0 1 0 permanent subscriber-address-assignment 1 1 0 permanent subscriber-vlan 0 1 0 permanent subscriber-ip 0 1 0 permanent service-dc 0 1 0 permanent service-accounting 0 1 0 permanent service-qos 0 1 0 permanent service-ancp 0 1 0 permanent service-cbsp 0 1 0 permanent scale-subscriber 1 1000 0 permanent scale-l2tp 0 1000 0 permanent scale-mobile-ip 0 1000 0 permanentLicenses installed: License identifier: E000185416 License version: 2 Features: subscriber-accounting - Per Subscriber Radius Accounting permanent subscriber-authentication - Per Subscriber Radius Authentication permanent subscriber-address-assignment - Radius/SRC Address Pool Assignment permanent subscriber-vlan - Dynamic Auto-sensed Vlan permanent subscriber-ip - Dynamic and Static IP permanentLicense identifier: E001171420 License version: 2 Features: service-dc - Service Definition Capability permanent service-accounting - Per Service Accounting permanent service-qos - Dynamic QOS Policy permanent service-ancp - ANCP Based QOS Adjustment permanent service-cbsp - Cell Based Shaping and Policing permanent


Configuring the Loopback Interface

In this book’s configuration, the interface ge-2/2/0 uses the loopback interface 10.10.10.149/32. This address was previously configured in the MX and since the same subnet, 10.10.10.0/24, is used for the DHCP pool, there is no need to add secondary addresses. Make sure that the loopback address is not given out in the pool range. Using the loopback address is referred to as using an unnumbered interface, where the unnumbered interface borrows the ip address from the loopback interface.

[edit] root@Camlab# show interfaces lo0.0 family inet { address 10.10.10.149/32; }

MORE? There are a number of uses for the unnumbered interfaces, including secondary addresses, primary, preferred, and using a number of secondary addresses for multiple DHCP pools. For more information go to http://www.juniper.net/techpubs/ and search for unnumbered interfaces.

Configuring ge-2/2/0

The ge-2/2/0 interface configuration stanza is very simple and it’s under unit 0:

[edit] root@Camlab# show interfaces ge-2/2/0 enable; unit 0 { demux-source inet; family inet { unnumbered-address lo0.0; } }

The configuration is using a demux-source inet (IPV4) and using the loopback interface address (lo0.0 or 10.10.10.149). For more VLAN and Stacked VLAN specific use cases, see Day One: Dynamic Sub-scriber Management at www.juniper.net/dayone.

Configuring the DHCP Local Server

The DHCP local server configuration is comprised of three pieces: first is the local address pool with DHCP attributes, second is the attributes controlling the pool, and third is the access profile.

http://www.juniper.net/techpubs/



In Junos, you configure multiple pools in the [access address-assign-ment] hierarchy, and control in the [system services dhcp-local-server] hierarchy.

For this book’s lab example, the DHCP pool is configured as:

[edit access address-assignment] root@Camlab# show pool DHCP { family inet { network 10.10.10.0/24; range 1 { low 10.10.10.50; high 10.10.10.60; } dhcp-attributes { maximum-lease-time 3600; name-server { 8.8.8.8; } router { 10.10.10.149; } } } }

The example shows a pool name, DHCP, using the 10.10.10.0/24 subnet. The pool is a single range of addresses and returns a DNS server (8.8.8.8) along with a default gateway equal to the lo0.0 address. (10.10.10.149)

Next, the DHCP service is configured as follows in the [system service dhcp-local-server] stanza:

[edit system services dhcp-local-server] root@Camlab# show pool-match-order { ip-address-first; } authentication { username-include { user-prefix foobar; mac-address; } } dynamic-profile IPDemux; group local { interface ge-2/2/0.0; }

In this configuration the statement pool-match-order uses the ip-ad-dress-first to select the DHCP pool to use. Authentication is set up to


use the tag foobar, along with MAC address of the client, to create a user name. This is important when RADIUS is used to authorize the connection. The statement dynamic-profile points to the dynamic profile name that is configured in the next section. Also, you can see that the interface ge-2/2/0 is referenced to specify which interfaces will use this DHCP configuration.

Since the preceding configuration specified a user name under the authentication hierarchy, the authentication access control needs to be configured:

[edit access] root@Camlab# show profile local { authentication-order none; }root@Camlab# top [edit]root@Camlab# edit access-profile [edit access-profile] root@Camlab# show local;

For now it’s set to none, but going forward it will become RADIUS and use the username foobar.<mac address> as the username for the RADIUS access request.

Configuring the Dynamic Profile

The last configuration piece in setting up the use case for this book is adding the dynamic profile used to create the ipdemux subscriber connection. In the preceding configuration [system services dhcp-local-server] it is specified to use a dynamic profile called IPDemux. The dynamic profile uses $junos variables, and the variables are filled in with values when triggered by packets arriving at the interface.

[edit dynamic-profiles] root@Camlab# show IPDemux { interfaces { demux0 { unit "$junos-interface-unit" { demux-options { underlying-interface "$junos-underlying-interface"; } family inet { demux-source { $junos-subscriber-ip-address; } unnumbered-address lo0.0; }


} } } }

In this configuration, Junos fills in the $junos variables creating the subscriber connection.

Checkpoint – Validating the Configuration

Okay. At this point, the network configuration shown in Figure 2.1 should be active. When the DHCP client enables its Ethernet port, the MX should allocate an IP address from the DHCP pool and build a demux interface. The first place to look is on the client PC to see if an IP address is being assigned. Here’s an example from Windows 7:

And the IPv4 address allocated is 10.10.10.57 along with the default gateway of 10.10.10.149 and a DNS server 8.8.8.8. The MAC address is 00-50-56-BD-00-35, which, when preceded by foobar, should be the username associated with this subscriber.

Let’s check the connection on the MX with a show command:

[edit] root@Camlab# run show subscribers Interface IP Address/VLAN ID User Name LS:RI demux0.1073741886 10.10.10.57 foobar.0050.56bd.0035 default:default


The MX has assigned the interface name demux0.1073741886 to this subscriber with a user name of foobar.0050.56bd.003. The MAC address is formatted a little differently in Junos than it is in Windows, and it’s important to note this because in later chapters the user name format needs to match what is input into RADIUS.

To see the MX local DHCP server bindings:

root@Camlab# run show dhcp server binding IP address Session Id Hardware address Expires State Interface 10.10.10.57 38918 00:50:56:bd:00:35 2027 BOUND ge-2/2/0.0

Using the interface name demux0.1073741886 in the show subscribers command, details on the actual subscriber can be retrieved:

[edit] root@Camlab# run show interfaces demux0.1073741886 Logical interface demux0.1073741886 (Index 141076) (SNMP ifIndex 653) Flags: SNMP-Traps 0x4000 Encapsulation: ENET2 Demux: Underlying interface: ge-2/2/0.0 (Index 329) Family Inet Source prefixes, total 1 Prefix: 10.10.10.57/32 Input packets : 15011 Output packets: 25622 Protocol inet, MTU: 1500 Flags: Sendbcast-pkt-to-re, Unnumbered Donor interface: lo0.0 (Index 321)

TIP There are several other commands you can use to drill down into the subscriber connection, which you can access using simple Junos help <?> prompt.

Adding Firewall Filters to the Configuration

At this point, the subscriber is connected but there is no firewall attached. The subscriber is free to send and receive at whatever speed it can handle. For this book, the subscriber will be applied with a firewall filter that has a simple policer associated with it. The policer will be a 2M policer for both input and output. Definitions for a 5M and 10M policer will also be configured at this time to be used for the CoA.

MORE? Firewall filters are very powerful and our configuration is just using a small subset, so to get an idea of the kinds of things that can be done, please see http://www.juniper.net/techpubs/ and search for firewall filters. Also, visit the Day One library at http://www.juniper.net/dayone for several books that include firewall filter creation.





To begin the configuration, the firewall filter needs a name and actions associated with it. The filters are defined in the top level of the hierar-chy as follows:

[edit] root@Camlab# show firewall family inet { filter police-10M { interface-specific; term all { then policer 10M; } } filter police-2M { interface-specific; term all { then policer 2M; } } filter police-5M { interface-specific; term all { then policer 5M; } } } policer 2M { if-exceeding { bandwidth-limit 2m; burst-size-limit 100k; } then discard; } policer 5M { if-exceeding { bandwidth-limit 5m; burst-size-limit 250k; } then discard; } policer 10M { if-exceeding { bandwidth-limit 10m; burst-size-limit 500k; } then discard; }

Essentially these firewall filters are accepting all traffic (term all) and then invoking a policer, which has a bandwidth limit along with a burst size – when the traffic exceeds the bandwidth limit, it is discarded. The burst-size-limit is a byte count, not bits, as in bandwidth-limit. It’s


used to allow periodic bursts of traffic above the bandwidth-limit according to a single token bucket algorithm.

MORE? For a more detailed description on burst-size-limit, please see http://www.juniper.net/techpubs/ and search for burst-size-limit.

With the firewall filters defined, they now get added to the dynamic-profile, which was configured previously. For now, the filter gets added directly by name, using the police-2M as a starting point. After the SBR is brought into the configuration, it will be modified to a $junos variable and the name - police-2M - will be returned by RADIUS.

To add the firewall filter to the dynamic profile under the [family inet filter] hierarchy:

[edit] root@Camlab# show dynamic-profiles IPDemux { interfaces { demux0 { unit "$junos-interface-unit" { demux-options { underlying-interface "$junos-underlying-interface"; } family inet { demux-source { $junos-subscriber-ip-address; } filter { input police-2M; output police-2M; } unnumbered-address lo0.0; } } } } }

NOTE At this point, the DHCP client needs to be released from its previous DHCP bindings before the configuration can be committed. Junos will not allow a change to a dynamic profile that is in use by a subscriber.

This is done using the clear command or run clear from the [edit] menu:

clear dhcp server bindings all

After clearing the bindings, the new configuration should commit.

Starting with Junos 11.4, you can do dynamic profile versioning, which allows changes when subscribers are using a profile.




After the new configuration is committed, disable and enable the Ethernet NIC on the DHCP client and use the following commands to check for the proper firewall filter assignment:

[edit] root@Camlab# run show subscribers Interface IP Address/VLAN ID User Name LS:RI demux0.1073741888 10.10.10.58 foobar.0050.56bd.0035 default:default

[edit] root@Camlab# run show firewall Filter: __default_bpdu_filter__ Filter: police-2M-demux0.1073741888-in Policers: Name Bytes Packets 2M-all-demux0.1073741888-in 5156618 13642Filter: police-2M-demux0.1073741888-out Policers: Name Bytes Packets 2M-all-demux0.1073741888-out 386540 266

As the output of the show firewall command shows, filter name 2M-all-demux0.1073741888-in contains all the relevant information, speed, type of traffic, demux number and direction. It also shows a byte/packet count of traffic that is processed by the filter.

Summary

At this point you should have a working DHCP client with ingress and egress firewall filters assigned limiting traffic to 2Mbps. You should also have a good understanding of how the MX uses dynamic profiles in DHCP applications as well as the concepts of firewall filters being used as a policer.

In the next chapter, SBR will be introduced to control the authoriza-tion of the DHCP client, in addition to assigning the firewall filter to the client. Go get a cup of coffee or your favorite beverage and let’s get ready for SBR.


Chapter 3

Adding SBR to the Configuration

Licensing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Loading SBR Onto a Centos or Red Hat Server (or VM) . . . . . . . . . . . . . . . . 28

Configuring SBR Text Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Configuring SBR RADIUS Clients, Profiles, and Users . . . . . . . . . . . . . . . . . . 34

Configuring the MX for Radius Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Testing the Configuration - Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50


This chapter describes the setup of SBR Carrier to control the authori-zation and firewall filter assignment of the MX setup for the previous chapters. The steps covered for doing so are:

� License requirements

� Loading SBR onto a Centos platform (VM or physical server)

� Configuring SBR text files

� Configuring SBR users, profiles, and RADIUS clients

� Configuring MX to use SBR for authorization

� Debugging using SBR and MX logs

Licensing Requirements

SBR requires two licenses for this application:

� A base license to run the server (SKU: SBR-CAR-AAA)

� And a license for Change of Authorization (SKU: SBR-CAR-SCM)

SCM stands for Session Control Module and allows for CoA/DM, as well as for Cisco IOS’s Packet of Disconnect (POD). The licenses are installed when the SBR configure script is run on the server. These licenses can also be the lab version, which simply adds –LAB to the SKU. In production environments, SBR is typically used with the Session State Registrar (SSR), which centralizes the session state from a number of SBR front end servers. This book, however, focuses on the standalone SBR server.

Loading SBR Onto a Centos or Red Hat Server (or VM)

The first step to get SBR onto a server is to build the server or Virtual-Machine (VM). VM Player can boot from a Centos or Red Hat ISO image.

Centos download mirrors are available here: http://www.centos.org/modules/tinycontent/index.php?id=30 . After downloading the latest 6.X OS, it can be mounted in VM Player and launched as a Centos machine.

The process of loading SBR onto Linux is straightforward and de-scribed in the SBR install guide (get it here: http://www.juniper.net/techpubs/ and search for Steel Belted Radius Install). If you just want to install the SBR rpm without the manual, simply load the rpm file into a tmp directory on the Linux server, then execute: yum localin-stall <sbr rpm file name>.

http://www.centos.org/modules/tinycontent/index.php?id=30

http://www.centos.org/modules/tinycontent/index.php?id=30



Chapter3:AddingSBRtotheConfiguration 29

Many LINUX distributions come with iptables configured and will block the ports needed for SBR and RADIUS, specifically UDP and TCP 1812/1813. SBR also configures the older RADIUS ports 1645/1646; however, these won’t be used in this book. To turn off iptables, simply enter the following on the LINUX server as root:

[root@src-linux RADIUS]# /etc/init.d/iptables stop iptables: Flushing firewall rules: [ OK ] iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Unloading modules: [ OK ] [root@src-linux RADIUS]#

This will stop the iptables firewall until next time you reboot the system. To turn it off permanently, use:

chkconfig iptables stop

After doing the yum localinstall of the rpm, the next step is to run the configure script:

[root@src-linux ~]# cd /opt/JNPRsbr/RADIUS/install [root@src-linux install]# ./configure Configuring SBR Software--------------------------------------------------------------------------- SBR 7.40.21552 on Linux 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22 GMT 2011 node src-linux ---------------------------------------------------------------------------

After you accept the license agreement, prompts for the aforemen-tioned SBR licenses are provided. Enter the two required licenses:

� Enter SBR full license: <SBR-CAR-AAA license>

� Enter SBR feature license: <SBR-CAR-SCM license>

When both licenses are accepted, press the Enter key and the configure script continues. For most of the configuration prompts the default is acceptable. (For more information on each of the prompts see the SBR Installation Guide.) For this book, just make sure it’s a <new> installa-tion, and enable the autoboot script (these are default).

Once the configure script is finished, start SBR, and test the access to the Admin GUI.

Start SBR by navigating to the /opt/JNPRsbr/RADIUS directory – this is the default directory where most of the configuration work is done. From this directory run the sbrd script as follows:

[root@src-linux RADIUS]# cd /opt/JNPRsbr/RADIUS/ [root@src-linux RADIUS]# ./sbrd start Starting RADIUS server processes RADIUS: Process ID of daemon is 15763 RADIUS: Starting DCF system [root@src-linux RADIUS]# RADIUS:


RADIUS: Steel-Belted Radius licenses RADIUS: License String: Additional Info: RADIUS: 08200011021412490001000117107879 Run license - expires 6/3/2013 - 1k sessions RADIUS: 1820002502141266051207548474 Session Control (CoA/DM) feature - expires 6/20/2013 RADIUS: 1820004302141266000819546320 JavaScripting feature - expires 6/20/2013 RADIUS: RADIUS: Total concurrent sessions licensed: 1000 RADIUS: RADIUS: Licenses enable this server to: RADIUS: Run RADIUS: use JavaScripting feature RADIUS: use Session Control (CoA/DM) feature RADIUS: RADIUS: Licensed for Steel-Belted Radius Carrier RADIUS: Attribute Editing enabled RADIUS: DCF system started RADIUS: LDAP Configuration Interface (LCI) is not enabled

If SBR has an error launching, check the /etc/hosts file on the server for the IP address that SBR is using. The SBR software must be able to resolve its address to the hostname. Here you see the hostname src-linux has been added to /etc/hosts to allow SBR to start:

[root@src-linux RADIUS]# hostname src-linux[root@src-linux RADIUS]# more /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.10.10.102 src-linux [root@src-linux RADIUS]#

The sbrd script has a number of functions other than start; you can see these by entering ./sbrd <return> as follows:

[root@src-linux RADIUS]# ./sbrdSYNOPSIS: sbrd <function> [force]EXAMPLES: sbrd status sbrd start [force] sbrd stop [force] sbrd restart [force] sbrd clean [force] sbrd hup

Once SBR has started successfully, bring up the admin GUI interface from Internet Explorer or Firefox by navigating to http://<server-ad-dress>:1812.


Click on the launch button and SBR launches a java applet, which is the Admin GUI.

NOTE SBR admin GUI runs on IE and Firefox with java enabled. If you have trouble launching the admin GUI, but can get to the web server, check the java configurations.


Configuring SBR Text Files

There are two parts to configuring SBR for operation, text files and admin GUI. Depending on the complexity of the configuration, different files and GUI panels need to be configured. For the simple configuration being used in this book, there are only a couple of file modifications needed, but be patient as there is more complex file editing later for CoA support.

RADIUS.ini

The RADIUS.ini file contains a number of global settings specific to the instance of RADIUS. The file is lengthy, but only a couple of areas need to be edited:

[Logging] LogLevel=2 TraceLevel=2 LogAccept=1 LogReject=1 ;MaxSize = 0 ;RollOver = 0 ;LogfileMaxMBytes = 0 ;LogfilePermissions = owner:group mode ; UNIX only ;LogHighResolutionTime = no ;LogUsesUTC = no ;EnhancedDiagnosticLogging = no ;Log-Thread-ID = no ;Log-Flush-To-System = no ;LogCallingStationId = no ;LogSessionId = no ;LogDir = <file system location> ;The following setting will display the system information at rollover ;SysInfoOnRollover = yes

Use your favorite editor and change the two bolded parameters, LogLevel and TraceLevel, to 2. This turns on verbose logging, which will be used in all subsequent chapters for debugging.

NOTE Verbose logging should not be used in a production network because of performance considerations.

If you’re following along in a lab, the second area to edit may or may not be required, depending on the server configuration: the Addresses section.

[Addresses] ; This section controls which IP addresses the server will listen on for ; incoming RADIUS packets. By default, the server will use DNS (and DNSv6 if ; IPv6 is enabled) to configure all local IP addresses except for the following: ; IPv4/IPv6 loopback, IPv6 link local (DEPRECATED), IPv6 site local (DEPRECATED). ; Alternatively, one or more IP addresses may be specified explicitly, each on


; a separate line, in which case only the specified addresses will be configured. ; Zero or more of the following AutoConfigure directives may also be specified: ;AutoConfigureIPv4 ; Use DNS to configure all local IPv4 addresses ;AutoConfigureIPv6 ; Use DNSv6 to configure all local IPv6 addresses 10.10.10.102

The Addresses section is simply used to specify the IP addresses (ports on the server) that are needed for the RADIUS process to listen on. In a typical VM installation there’s only one port, so configuring the address is not needed. In multiple NIC installations, there may be a requirement not to listen on certain ports. If that’s the case, simply type in the IP addresses that you need RADIUS to listen to on the server, as shown above in bold.

vendor.ini

SBR uses dictionary files to process the RADIUS attributes (both standard RADIUS and VSAs). In the case of the lab MX for this book, the VSA dictionary being used is unisphereMX11-2.dct. Viewing this file lists all of the attributes used by the MX for subscriber manage-ment. The Juniper subscriber management VSAs are built off of the Unisphere VSAs used by the ERX router, hence the dictionary needed is the same for either an ERX or a MX running subscriber manage-ment.

NOTE It’s important to note that SBR only processes RADIUS packets using the dictionary associated with the product listed in vendor.ini, along with the standard RADIUS.dct attributes.

Edit the file vendor.ini and search for the entry with Unishphere MX with Junos v11.2 as shown. Ensure the correct dictionary is associated with the vendor-product.

vendor-product = Unisphere MX with JUNOS v11.2 dictionary = unisphereMX11-2 ignore-ports = no port-number-usage = per-port-type help-id = 2000

The vendor-product = is the text string that is seen in the SBR admin GUI when configuring the MX.

After the edits are done to the text files, restart or hup the sbr process as root.in the /opt/JNPRsbr/RADIUS directory:

./sbrd restart

or

./sbrd hup


Configuring SBR RADIUS Clients, Profiles, and Users

The next step in configuring SBR is defining the MX and the user and the user profiles associated with the DHCP client from Chapter 2. Let’s start with clients.

RadiusClient(theMX)

To configure the RADIUS client, start at the RADIUS client tab in the left panel and click on Add in the lower menu bar. (There is a short cut for configuring RADIUS clients by choosing any IP address, but alas, this won’t work with CoA, so each client is configured specifically).

After clicking on Add, the Edit RADIUS CLIENT panel appears. Choose a name and set the address of the MX, 10.10.10.101 in our case, and testing123 as a shared secret (this is defaulted as masked). Select the Make or Model as was entered in your vendor.ini. Leave it 3799 in the RFC 3576 CoA/DM port field, and use the same shared secret that RADIUS uses.


When you’re done click OK, and the client is added. There’s no need to hup or restart with changes you make in the admin GUI.

Profiles

In SBR, profiles are simply lists of attributes that either are expected to be received in an access request (checklist) or returned in an access accept (return list). In the use case for this book checklists won’t be used. However, the attributes corresponding to the police-2M firewall filter defined in the MX will be set up in the return list. This profile will be called slow – for obvious reasons.

There are two attributes (VSAs) required to implement this firewall filter.

� Unisphere-Ingress-Policy-Name

� Unishphere-Egress-Policy-Name.

These attributes correspond to the filter in the dynamic profile below. When the MX is configured for RADIUS, the input police-2M and output police-2M filters can be replaced with $junos variables, mean-


ing the MX expects RADIUS to return values for these firewall filter names:

IPDemux { interfaces { demux0 { unit "$junos-interface-unit" { demux-options { underlying-interface "$junos-underlying-interface"; } family inet { demux-source { $junos-subscriber-ip-address; } filter { input police-2M; output police-2M; } unnumbered-address lo0.0; } } } } }

SettingUptheProfileReturnList

To set up the profile return list, click on profiles in the left panel of the SBR admin GUI and then click on Add.

Give the profile the name slow and click on the Return List tab in the Attributes detail. Click on Add and look for Unisphere-Ingress-Policy-Name and input a value of police-2M, and then do the same for Unisphere-Egress-Policy-Name. When you select Add in the attribute list, the list contains attributes that are in the RADIUS.dct file as well as the unisphereMX11-2.dct file configured in vendor.ini. Only


attributes that are valid in a return list are shown.

MORE? There are many attributes corresponding to dynamic profile and Class of Service settings in the MX discussed in Chapter 1.

NativeUsers

A user database that is internal to the SBR server is called native users. It’s meant to support small installations (10K users or less). In service provider networks, the subscriber database is typically a SQL or LDAP repository SBR connects to that allows authentication and authoriza-tion. In this book, let’s just use the internal database for simplicity.

The native user’s panel in SBR admin GUI allows you to add users/password and profiles for each subscriber. Profiles are pointers to lists of attributes that you want returned with the access accept message. Looking back at Chapter 2, the DHCP subscriber was given a user name of foobar.0050.56bd.0035, built from user-prefix foobar, and the mac-address of the DHCP client:

authentication { username-include { user-prefix foobar; mac-address;

When the MX is configured for RADIUS, a password of juniper will be used for this user. The profile will be called slow, which was configured previously, thus indicating the 2M policers defined in the MX.

To add the user, expand the user’s panel in the left-hand pane and open native users.


Then click Add in the taskbar and input the user name, password, and profile name as shown here. The name is not case sensitive as RADIUS defaults to this, so the user name will be in caps.

Once done click OK, and that’s all that’s needed for the SBR. The server will wait for an access request from the MX containing the user-name/password defined, and if it matches, the server will return the ingress and egress profile names to the MX.

Configuring the MX for Radius Authorization

The final step is to configure the MX to request authorization from SBR. The network now has the following components shown in Figure 3.1.

To configure the MX to talk to RADIUS let’s start with adding the password juniper to the user-name. The password field must be present in a RADIUS access request, even though all users will share the same password. The password in this case is not technically authentication, just authorization and compliance to RFCs. It’s called authentication server in the MX, but again, technically it’s authorization of the user-name. This configuration is done in the [edit system services dhcp-local-server] hierarchy:


Figure 3.1 Configure the MX to Request Authorization

[edit system services dhcp-local-server] root@Camlab# set authentication password juniper [edit system services dhcp-local-server] root@Camlab# show traceoptions { ## Warning: 'traceoptions' is deprecated file dhcp-server-msgs.log size 10m world-readable; flag all; } pool-match-order { ip-address-first; } authentication { password juniper; username-include { user-prefix foobar; mac-address; } } dynamic-profile IPDemux; group local { interface ge-2/2/0.0; }[edit system services dhcp-local-server] root@Camlab#


NOTE Most service providers would use DHCP option 82 as the user name, which is an option, on the MX – DHCP Option 82, is built up from two sub options, Circuit ID and Remote ID, and is used by the service provider to identify where the actual connection is coming from, and ultimately the profile that should be returned.

Next the MX needs an access profile defined (called sbr here). This includes the RADIUS specific configuration. The configuration is defined under the [edit access profile sbr] heirarchy:

[edit access profile sbr] root@Camlab# show accounting-order RADIUS; authentication-order RADIUS; RADIUS { authentication-server 10.10.10.102; accounting-server 10.10.10.102; options { revert-interval 0; } } RADIUS-server { 10.10.10.102 { secret "$9$Hk5FCA0IhruOrv87sYGDikfTFn/t0B"; ## SECRET-DATA source-address 10.10.10.101; } } accounting { order RADIUS; immediate-update; update-interval 10; }[edit access profile sbr] root@Camlab#

Under the RADIUS-server stanza, the secret corresponds to the same shared secret entered on SBR – testing123. It’s masked in Junos.

Accounting and authentication have been configured. Accounting needs to be configured since SBR builds its current session table based on accounting and not authorization. There is an update-interval set to 10 minutes, which means the MX will send interim accounting updates at that interval for the duration of the session. When the MX generates an accounting packet (start/stop or interim), it will include an attribute called accounting-session-id. This attribute value is what SBR and the MX will use to generate CoA messages later in the book. It’s essentially a unique value for this subscriber session.

Since SBR will return two attributes in the access accept, ingress, and egress policy names, the dynamic profile needs updating to reflect this. The input and output filters that directly referenced police-2M in


Chapter 2, now need to be configured to look for RADIUS to return the value. This is done by adding the variables $junos-input-filter and $junos-output-filter to the dynamic profile. (There is an exten-sive list of $junos variables and how they relate to RADIUS attributes in the Junos Subscriber Access Configuration Guide.) The dynamic profile now looks like the following:

[edit dynamic-profiles] root@Camlab# show IPDemux { interfaces { demux0 { unit "$junos-interface-unit" { demux-options { underlying-interface "$junos-underlying-interface"; } family inet { demux-source { $junos-subscriber-ip-address; } filter { input "$junos-input-filter"; output "$junos-output-filter"; } unnumbered-address lo0.0; } } } } }[edit dynamic-profiles] root@Camlab#

Last, but certainly not least, the MX needs to be told to use the access profile called sbr. In Chapter 2, the access profile was named local, which didn’t have any authentication defined:

[edit] root@Camlab# set access-profile sbr [edit] root@Camlab# commit commit complete[edit]

Testing the Configuration - Logs

There have been several configuration changes up to this point. To begin the testing, you need to confirm that the MX is sending an access request to SBR; this is the first step after receiving the DHCP request on the MX, which was tested in Chapter 2.


The MX log used is the general-authentication-service log, which shows messages related to authentication – in this case RADIUS. Here is the configuration of that log:

[edit system] root@Camlab# edit processes [edit system processes] root@Camlab# show general-authentication-service { traceoptions { file authd size 10m; flag all; } }[edit system processes] root@Camlab#

It may be required to look at the dhcp-local-server log as another step in debugging. This log shows messages related to the DHCP local server. Since it’s been tested in Chapter 2, we won’t use it here, but if it’s required by you in your own lab, the configuration of that log file is shown here:

[edit] root@Camlab# edit system services [edit system services] root@Camlab# show ftp; ssh; telnet; dhcp-local-server { traceoptions { ## Warning: 'traceoptions' is deprecated file dhcp-server-msgs.log size 10m world-readable; flag all; } pool-match-order { ip-address-first; } authentication { password juniper; username-include { user-prefix foobar; mac-address; } } dynamic-profile IPDemux; group local { interface ge-2/2/0.0; } }[edit system services] root@Camlab#


In both of these traceoptions configurations the log file name is specified along with flag all. Flag all makes these logs extremely verbose and you may want to have more specific flag options.

MORE? See the Junos OS Subscriber Access Configuration Guide at http://www.juniper.net/techpubs/ for specifics on flag settings.

Monitorgeneral-authentication-serverLog

Now let’s show log messaging taking place in the MX as it processes the RADIUS messages for both access request and accounting start. Note that several sections of the log have been removed for brevity, and other areas have been bolded to check for configuration errors.

MX access request:

root@Camlab> monitor start authd root@Camlab> *** authd *** Nov 13 19:01:06 ################################################################### Nov 13 19:01:06 ########################### AUTH REQ RCVD ######################### Nov 13 19:01:06 ################################################################### Nov 13 19:01:06 Auth-FSM: Process Auth-Request for session-id:17 Nov 13 19:01:06 Framework: Starting authentication Nov 13 19:01:06 authd_advance_module_for_aaa_request_msg: result:0 Nov 13 19:01:06 Authd module start Nov 13 19:01:06 authd_RADIUS_start_auth: Starting RADIUS authentication Nov 13 19:01:06 authd_RADIUS_build_basic_auth_request: got params profile=sbr, username=foobar.0050.56bd.0035 Nov 13 19:01:06 RADIUS-access-request: User-Name added: foobar.0050.56bd.0035 Nov 13 19:01:06 RADIUS-access-request: User-Password added: "" Nov 13 19:01:06 Number of default include attributes:53 for msg-type:1 Nov 13 19:01:06 RADIUS-access-request: Service-Type added: 2 Nov 13 19:01:06 RADIUS-access-request: Chargeable-User-Identity added: Nov 13 19:01:06 RADIUS-access-request: Acct-Session-Id added: 17 Nov 13 19:01:06 RADIUS-access-request: DHCP-Options (Juniper-ERX-VSA) added: 35 01 01 3d 07 01 00 50 56 bd 00 35 0c 07 53 52 43 2d 50 43 32 3c 08 4d 53 46 54 20 35 2e 30 37 0c 01 0f 03 06 2c 2e 2f 1f 21 79 f9 2b Nov 13 19:01:06 ../../../../../src/junos/usr.sbin/authd/plugin/RADIUS/authd_plugin_RADIUS_module.cc:840:mac_addr_buf = <0050.56bd.0035> Nov 13 19:01:06 RADIUS-access-request: DHCP-MAC-Address (Juniper-ERX-VSA) added: 0050.56bd.0035 Nov 13 19:01:06 RADIUS-access-request: NAS-Identifier added: Camlab Nov 13 19:01:06 RADIUS-access-request: NAS-Port added: 20 00 0f ff Nov 13 19:01:06 RADIUS-access-request: NAS-Port-Id added: ge-2/2/0.0 Nov 13 19:01:06 RADIUS-access-request: NAS-Port-Type added: 15 Nov 13 19:01:06 authd_create_application_specific_RADIUS_server: Evaluating RADIUS server 0x660a0a0a to add to the server list Nov 13 19:01:06 Verify source address 650a0a0a (10.10.10.101) in routing instance index=0




Nov 13 19:01:06 REQUEST: AUTHEN - module_index 0 module(RADIUS) return: ASYNC Nov 13 19:01:06 Auth-FSM: GRES-Mirror for session-id:17 state:AuthStart(1) Nov 13 19:01:06 authd_RADIUS_get_config:Using RADIUS option config from access profile stanza Nov 13 19:01:06 RADIUS server 10.10.10.102:1812 was used for last request Nov 13 19:01:06 ../../../../../src/junos/usr.sbin/authd/aaa-service/authd_aaa_subscriber_entry.cc:2268 Could not find the requested authd attribute 10171 Nov 13 19:01:06 Failed to get default service name Nov 13 19:01:06 Radius result is CLIENT_REQ_STATUS_SUCCESS Nov 13 19:01:06 RADIUS-access-accept: Class received: 53 42 52 32 43 4c fd af fa 88 a7 ea ff d0 c2 80 11 80 34 01 80 02 81 98 80 02 80 18 81 a3 93 e9 f4 92 85 a4 ae 98 8c 86 d3 81 b8 ea b6 a1 91 85 e3 81 c0 e6 b5 12 80 0e 81 fd af fa 88 a3 be 97 91 a8 80 80 80 80 a8 Nov 13 19:01:06 RADIUS-access-accept: Egress-Policy-Name (Juniper-ERX-VSA) received: police-2M Nov 13 19:01:06 RADIUS-access-accept: Ingress-Policy-Name (Juniper-ERX-VSA) received: police-2M Nov 13 19:01:06 Framework - module(RADIUS) return: SUCCESS

MXDHCPAddressAllocation

This next section of the general authentication log is where the DHCP local server has assigned the IP address to the subscriber based on the success of the RADIUS access request. Since the address is assigned prior to the accounting start message being sent to RADIUS, the accounting start will contain the attribute framed-ip-address. This is used as the session identifier in the web portal application and is needed by many CoA applications. There are cases where the framed-ip-address may not be included in the accounting start message, so our configuration has, within the [access profile sbr] stanza:

accounting { order RADIUS; immediate-update; update-interval 10;

The setting immediate-update is used to force the MX to send an accounting interim immediately after the accounting start. The interim message should contain the framed-ip-address attribute even if it’s not available in time for the accounting start. Let’s take a look:

Nov 13 19:01:06 ************* Results of Address Allocation ************* Nov 13 19:01:06 DUMP of all addressRequest fields for subscriber 17 router default:default Nov 13 19:01:06 client type jdhcpd client type 1 mac address 00:50:56:BD:00:35 Nov 13 19:01:06 REQUESTING: OldStyle 0 OldStyleFilled 1 hint null network 10.10.10.149 client pool name Nov 13 19:01:06 Framed-Pool-->SDB_USER_IP_POOL 'DHCP' used for V4NA Nov 13 19:01:06 V4NA: req: yes pool: DHCP address: 10.10.10.54 Nov 13 19:01:06 V6NA: req: no pool: NULL address: null Nov 13 19:01:06 V6PD: req: no pool: NULL prefix: null/0


Nov 13 19:01:06 V6NDRA: req: no pool: NULL ndra prefix: null/0 Nov 13 19:01:06 ********************************************************* ################################################################### Nov 13 19:01:06 ######################### AUTH REQ ACK SENT ####################### Nov 13 19:01:06 ################################################################### Nov 13 19:01:06 Username:, Session-Id:17 Access-profile: Multi-Acct-Session-Id:0 Nov 13 19:01:06 ################################################################### Nov 13 19:01:06 ################## CLIENT/FAMILY ACTIVE RCVD ###################### Nov 13 19:01:06 ################################################################### Nov 13 19:01:06 haveServicesToProcess FAMILY_TYPE_INET, existing dynRequest, NO services Pending, Auth State AuthClntRespWait Nov 13 19:01:06 ~DynamicRequestEntryNov 13 19:01:06 Auth-FSM: Trigger Acct-Start, and post Subscriber-Activated-Ack to the client daemon. session-id:17 Nov 13 19:01:06 Auth-FSM: Trigger Acct-Start. session-id:17 Nov 13 19:01:06 ======= Accounting START triggered ============== Nov 13 19:01:06 checkLicense Nov 13 19:01:06 AccFsm::current state=Acc-Init(0) event=1 astEntry=0x8c6042c Nov 13 19:01:06 ACC-FSM:sendAccStart_a1 for session-id:17 Nov 13 19:01:06 Authd module Accounting Nov 13 19:01:06 Authd acctg module start Nov 13 19:01:06 authd_RADIUS_send_acctg_msg: Starting RADIUS accounting Nov 13 19:01:06 authd_RADIUS_send_acctg_msg: got params profile=sbr username=foobar.0050.56bd.0035 acctg_id=(17), ls=default, lr=default Nov 13 19:01:06 RADIUS-acct-start: User-Name added: foobar.0050.56bd.0035 Nov 13 19:01:06 RADIUS-acct-start: Acct-Status-Type added: 00 00 00 01 Nov 13 19:01:06 RADIUS-acct-start: Acct-Session-Id added: 17 Nov 13 19:01:06 Number of default include attributes:72 for msg-type:8 Nov 13 19:01:06 RADIUS-acct-start: Service-Type added: 2 Nov 13 19:01:06 RADIUS-acct-start: Acct-Authentic added: 1 Nov 13 19:01:06 RADIUS-acct-start: Acct-Delay-Time added: 0 Nov 13 19:01:06 RADIUS-acct-start: Class added: 53 42 52 32 43 4c fd af fa 88 a7 ea ff d0 c2 80 11 80 34 01 80 02 81 98 80 02 80 18 81 a3 93 e9 f4 92 85 a4 ae 98 8c 86 d3 81 b8 ea b6 a1 91 85 e3 81 c0 e6 b5 12 80 0e 81 fd af fa 88 a3 be 97 91 a8 80 80 80 80 a8 Nov 13 19:01:06 RADIUS-acct-start: DHCP-Options (Juniper-ERX-VSA) added: 35 01 01 3d 07 01 00 50 56 bd 00 35 0c 07 53 52 43 2d 50 43 32 3c 08 4d 53 46 54 20 35 2e 30 37 0c 01 0f 03 06 2c 2e 2f 1f 21 79 f9 2b Nov 13 19:01:06 ../../../../../src/junos/usr.sbin/authd/plugin/RADIUS/authd_plugin_RADIUS_module.cc:840:mac_addr_buf = <0050.56bd.0035> Nov 13 19:01:06 RADIUS-acct-start: DHCP-MAC-Address (Juniper-ERX-VSA) added: 0050.56bd.0035 Nov 13 19:01:06 RADIUS-acct-start: Egress-Policy-Name (Juniper-ERX-VSA) added: police-2M Nov 13 19:01:06 RADIUS-acct-start: Event-Timestamp added: 1352833266 Nov 13 19:01:06 RADIUS-acct-start: Framed-IP-Address added: 10.10.10.54 Nov 13 19:01:06 RADIUS-acct-start: Framed-IP-Netmask added: 255.255.255.0 Nov 13 19:01:06 RADIUS-acct-start: Ingress-Policy-Name (Juniper-ERX-VSA) added: police-2M Nov 13 19:01:06 RADIUS-acct-start: NAS-Identifier added: Camlab Nov 13 19:01:06 RADIUS-acct-start: NAS-Port added: 20 00 0f ff Nov 13 19:01:06 RADIUS-acct-start: NAS-Port-Id added: ge-2/2/0.0 Nov 13 19:01:06 RADIUS-acct-start: NAS-Port-Type added: 15 Nov 13 19:01:06 authd_create_application_specific_RADIUS_server: Evaluating RADIUS server 0x660a0a0a to add to the server list


Nov 13 19:01:06 Verify source address 650a0a0a (10.10.10.101) in routing instance index=0 Nov 13 19:01:06 ACC-FSM:start interim timer for session-id:17

SteelBeltedRadiuslogs

SBR logs are stored by default in the /opt/JNPRsbr/RADIUS directory and have the format YYYYMMDD.log. This is a basic text file and can be monitored using the Linux tail command. With the logging set to verbose (2) in RADIUS.ini, the log contains all packets received and processed by SBR. The log will have a raw packet dump as well as a parsed packet, showing the attributes and values, along with other relevant information. For the sake of brevity, in the dump below the log sections showing raw packet dump have been removed and the focus is on the parsed packet. Entries in bold are useful in debugging:

[root@src-linux RADIUS]# tail -f 20121113.log

11/13/2012 20:14:18.469 (2212): -------------------------------------------------------- 11/13/2012 20:14:18.469 (2212): Authentication Request 11/13/2012 20:14:18.469 (2212): Received from IpAddr=10.10.10.101 Port=62354 11/13/2012 20:14:18.469 (2212): 11/13/2012 20:14:18.469 (2303): Entering 11/13/2012 20:14:18.469 (2303): Looking up shared secret 11/13/2012 20:14:18.469 (2303): Looking for RAS client 10.10.10.101 in DB 11/13/2012 20:14:18.469 (2303): Matched 10.10.10.101 to RAS client MX 11/13/2012 20:14:18.469 (2303): Parsing request 11/13/2012 20:14:18.469 (2303): Initializing cache entry 11/13/2012 20:14:18.469 (2303): Doing inventory check on request 11/13/2012 20:14:18.469 (2303): Getting info on requesting client 11/13/2012 20:14:18.469 (2303): NAS-IP-Address in request: 10.10.10.101 11/13/2012 20:14:18.469 (2303): -------------------------------------------------------- 11/13/2012 20:14:18.469 (2303): Authentication Request 11/13/2012 20:14:18.469 (2303): Received from IpAddr=10.10.10.101 Port=62354 11/13/2012 20:14:18.469 (2303): Packet Code=0x01 Id=0x7f 11/13/2012 20:14:18.469 (2303): Client Name="MX" 11/13/2012 20:14:18.469 (2303): Dictionary Name="unisphereMX11-2.dct" 11/13/2012 20:14:18.469 (2303): Vector = 11/13/2012 20:14:18.469 (2303): 000: 4a 96 c0 0a df 0d b2 9d 82 02 90 69 8e 75 36 73 |J..........i.u6s| 11/13/2012 20:14:18.469 (2303): Parsed Packet : 11/13/2012 20:14:18.469 (2303): User-Name : String Value = foobar.0050.56bd.0035 11/13/2012 20:14:18.469 (2303): User-Password : Value = 11/13/2012 20:14:18.469 (2303): 000: 96 a4 fe 57 ff b0 25 68 3b 6c ed c5 5b fe 9d e3 |...W..%h;l..[...| 11/13/2012 20:14:18.469 (2303): Service-Type : Integer Value = 2 11/13/2012 20:14:18.469 (2303): Chargeable-User-Identity : String Value = 11/13/2012 20:14:18.469 (2303): Acct-Session-Id : String Value = 21 11/13/2012 20:14:18.469 (2303): Unisphere-Dhcp-Options : Value = 11/13/2012 20:14:18.469 (2303): 000: 35 01 01 3d 07 01 00 50 56 bd 00 35 0c 07 53 52


|5..=...PV..5..SR| 11/13/2012 20:14:18.469 (2303): 010: 43 2d 50 43 32 3c 08 4d 53 46 54 20 35 2e 30 37 |C-PC2<.MSFT 5.07| 11/13/2012 20:14:18.469 (2303): 020: 0c 01 0f 03 06 2c 2e 2f 1f 21 79 f9 2b |.....,./.!y.+ | 11/13/2012 20:14:18.469 (2303): Unisphere-Dhcp-Mac-Addr : String Value = 0050.56bd.0035 11/13/2012 20:14:18.469 (2303): NAS-Identifier : String Value = Camlab 11/13/2012 20:14:18.469 (2303): NAS-Port : Integer Value = 536875007 11/13/2012 20:14:18.469 (2303): NAS-Port-ID : String Value = ge-2/2/0.0 11/13/2012 20:14:18.469 (2303): NAS-Port-Type : Integer Value = 15 11/13/2012 20:14:18.469 (2303): NAS-IP-Address : IPAddress = 10.10.10.101 11/13/2012 20:14:18.469 (2303): ------------------------------------------------------- 11/13/2012 20:14:18.469 (2303): Determining if request is for a tunnel 11/13/2012 20:14:18.469 (2303): Determining if this RADIUS should act as a proxy 11/13/2012 20:14:18.469 (2303): Determining user class 11/13/2012 20:14:18.470 (2303): Authenticating user FOOBAR.0050.56BD.0035 with authentication method Native User 11/13/2012 20:14:18.470 (2303): Determined that FOOBAR.0050.56BD.0035 of class Native-User is the user 11/13/2012 20:14:18.470 (2303): Getting attribute info on requesting user 11/13/2012 20:14:18.470 (2303): Getting profile info for requesting user 11/13/2012 20:14:18.470 (2303): Merging saved attributes with user info 11/13/2012 20:14:18.470 (2303): Merging profile info with user info 11/13/2012 20:14:18.470 (2303): Comparing checklist items with user/profile items 11/13/2012 20:14:18.470 (2303): Appending echo values, if any 11/13/2012 20:14:18.470 (2303): User FOOBAR.0050.56BD.0035 being passed to attribute editing authentication methods 11/13/2012 20:14:18.470 (2303): Class subattribute: DistName : String Value = FOOBAR.0050.56BD.0035 11/13/2012 20:14:18.470 (2303): Class subattribute: AuthType : String Value = 0 11/13/2012 20:14:18.471 (2303): Class subattribute: TransactionId : Value = 11/13/2012 20:14:18.471 (2303): 000: fa bf d0 84 6f 8b 91 50 00 00 00 0e |....o..P.... | 11/13/2012 20:14:18.471 (2303): Sent accept response for user FOOBAR.0050.56BD.0035 to client MX 11/13/2012 20:14:18.471 (2303): ------------------------------------------------------- 11/13/2012 20:14:18.471 (2303): Authentication Response 11/13/2012 20:14:18.471 (2303): Packet Code=0x02 Id=0x7f 11/13/2012 20:14:18.471 (2303): Vector = 11/13/2012 20:14:18.471 (2303): 000: 55 88 9b 87 b7 c2 97 27 cb cd 0f 8d 3f f7 04 85 |U......'....?...| 11/13/2012 20:14:18.471 (2303): Class : Value = 11/13/2012 20:14:18.471 (2303): 000: 53 42 52 32 43 4c fd af fa 88 a7 ea ff d0 c2 80 |SBR2CL..........| 11/13/2012 20:14:18.471 (2303): 010: 11 80 34 01 80 02 81 98 80 02 80 18 81 a3 93 e9 |..4.............| 11/13/2012 20:14:18.471 (2303): 020: f4 92 85 a4 ae 98 8c 86 d3 81 b8 ea b6 a1 91 85 |................| 11/13/2012 20:14:18.471 (2303): 030: e3 81 c0 e6 b5 12 80 0e 81 fd af fa 88 a3 be 97 |................| 11/13/2012 20:14:18.471 (2303): 040: 91 a8 80 80 80 80 b8


|....... | 11/13/2012 20:14:18.471 (2303): Unisphere-Egress-Policy-Name : String Value = police-2M 11/13/2012 20:14:18.471 (2303): Unisphere-Ingress-Policy-Name : String Value = police-2M 11/13/2012 20:14:18.471 (2303): -------------------------------------------------------- 11/13/2012 20:14:18.471 (2303): -------------------------------------------------------- 11/13/2012 20:14:18.471 (2303): Authentication Response 11/13/2012 20:14:18.471 (2303): Sent to IpAddr=10.10.10.101 Port=62354------------------------------------------------ 11/13/2012 20:14:18.634 (2211): Accounting Request 11/13/2012 20:14:18.634 (2211): Received from IpAddr=10.10.10.101 Port=62354 11/13/2012 20:14:18.634 (2211): -------------------------------------------------------- 11/13/2012 20:14:18.634 (3589): Looking up shared secret 11/13/2012 20:14:18.634 (3589): Looking for RAS client 10.10.10.101 in DB 11/13/2012 20:14:18.634 (3589): Matched 10.10.10.101 to RAS client MX 11/13/2012 20:14:18.634 (3589): Parsing request 11/13/2012 20:14:18.634 (3589): Initializing cache entry 11/13/2012 20:14:18.635 (3589): Doing inventory check on request 11/13/2012 20:14:18.635 (3589): Class subattribute: AuthType : String Value = 0 11/13/2012 20:14:18.635 (3589): Class subattribute: DistName : String Value = FOOBAR.0050.56BD.0035 11/13/2012 20:14:18.635 (3589): Class subattribute: TransactionId : Value = 11/13/2012 20:14:18.635 (3589): 000: fa bf d0 84 6f 8b 91 50 00 00 00 0e |....o..P.... | 11/13/2012 20:14:18.635 (3589): Getting client product information 11/13/2012 20:14:18.635 (3589): NAS-IP-Address in request: 10.10.10.101 11/13/2012 20:14:18.635 (3589): Setting data types 11/13/2012 20:14:18.635 (3589): -------------------------------------------------------- 11/13/2012 20:14:18.635 (3589): Accounting Request 11/13/2012 20:14:18.635 (3589): Received from IpAddr=10.10.10.101 Port=62354 11/13/2012 20:14:18.635 (3589): Packet Code=0x04 Id=0x80 11/13/2012 20:14:18.635 (3589): Client Name="MX" 11/13/2012 20:14:18.635 (3589): Dictionary Name="unisphereMX11-2.dct" 11/13/2012 20:14:18.635 (3589): Vector = 11/13/2012 20:14:18.635 (3589): 000: 62 67 8d 03 ff a5 31 f2 56 60 b1 0b 78 3b b5 84 |bg....1.V`..x;..| 11/13/2012 20:14:18.635 (3589): Parsed Packet : 11/13/2012 20:14:18.635 (3589): User-Name : String Value = foobar.0050.56bd.0035 11/13/2012 20:14:18.635 (3589): Acct-Status-Type : Integer Value = 1 11/13/2012 20:14:18.635 (3589): Acct-Session-Id : String Value = 21 11/13/2012 20:14:18.635 (3589): Service-Type : Integer Value = 2 11/13/2012 20:14:18.635 (3589): Acct-Authentic : Integer Value = 1 11/13/2012 20:14:18.635 (3589): Acct-Delay-Time : Integer Value = 0 11/13/2012 20:14:18.635 (3589): Class : Value = 11/13/2012 20:14:18.635 (3589): 000: 53 42 52 32 43 4c fd af fa 88 a7 ea ff d0 c2 80 |SBR2CL..........| 11/13/2012 20:14:18.635 (3589): 010: 11 80 34 01 80 02 81 98 80 02 80 18 81 a3 93 e9 |..4.............| 11/13/2012 20:14:18.635 (3589): 020: f4 92 85 a4 ae 98 8c 86 d3 81 b8 ea b6 a1 91 85


|................| 11/13/2012 20:14:18.635 (3589): 030: e3 81 c0 e6 b5 12 80 0e 81 fd af fa 88 a3 be 97 |................| 11/13/2012 20:14:18.635 (3589): 040: 91 a8 80 80 80 80 b8 |....... | 11/13/2012 20:14:18.635 (3589): Unisphere-Dhcp-Options : Value = 11/13/2012 20:14:18.635 (3589): 000: 35 01 01 3d 07 01 00 50 56 bd 00 35 0c 07 53 52 |5..=...PV..5..SR| 11/13/2012 20:14:18.635 (3589): 010: 43 2d 50 43 32 3c 08 4d 53 46 54 20 35 2e 30 37 |C-PC2<.MSFT 5.07| 11/13/2012 20:14:18.635 (3589): 020: 0c 01 0f 03 06 2c 2e 2f 1f 21 79 f9 2b |.....,./.!y.+ | 11/13/2012 20:14:18.635 (3589): Unisphere-Dhcp-Mac-Addr : String Value = 0050.56bd.0035 11/13/2012 20:14:18.635 (3589): Unisphere-Egress-Policy-Name : String Value = police-2M 11/13/2012 20:14:18.635 (3589): Event-Timestamp : Integer Value = 1352839139 11/13/2012 20:14:18.635 (3589): Framed-IP-Address : IPAddress = 10.10.10.58 11/13/2012 20:14:18.635 (3589): Framed-IP-Netmask : IPAddress = 255.255.255.0 11/13/2012 20:14:18.635 (3589): Unisphere-Ingress-Policy-Name : String Value = police-2M 11/13/2012 20:14:18.635 (3589): NAS-Identifier : String Value = Camlab 11/13/2012 20:14:18.635 (3589): NAS-Port : Integer Value = 536875007 11/13/2012 20:14:18.635 (3589): NAS-Port-ID : String Value = ge-2/2/0.0 11/13/2012 20:14:18.635 (3589): NAS-Port-Type : Integer Value = 15 11/13/2012 20:14:18.635 (3589): NAS-IP-Address : IPAddress = 10.10.10.101 11/13/2012 20:14:18.635 (3589): -------------------------------------------------------- 11/13/2012 20:14:18.635 (3589): Accounting packet not from cluster 11/13/2012 20:14:18.635 (3589): Determining if this RADIUS should act as a proxy 11/13/2012 20:14:18.635 (3589): ProcessAccountingRequest: new-style class attribute contains dn FOOBAR.0050.56BD.0035. 11/13/2012 20:14:18.635 (3589): Creating new CST record with Class attribute 11/13/2012 20:14:18.636 (3589): SessionDbc (INFO): UniqueSessionId is based on assigned IP address + 12 bytes of 0 11/13/2012 20:14:18.636 (3589): Sending accounting start response to client MX 11/13/2012 20:14:18.636 (3589): --------------------------------------------------------- 11/13/2012 20:14:18.636 (3589): Accounting Response 11/13/2012 20:14:18.636 (3589): Packet Code=0x05 Id=0x80 11/13/2012 20:14:18.636 (3589): Vector = 11/13/2012 20:14:18.636 (3589): 000: 97 44 72 ab b6 0f 09 29 83 86 6d fe ac 11 be 84 |.Dr....)..m.....| 11/13/2012 20:14:18.636 (3589): -------------------------------------------------------- 11/13/2012 20:14:18.636 (3589): -------------------------------------------------------- 11/13/2012 20:14:18.636 (3589): Accounting Response 11/13/2012 20:14:18.636 (3589): Sent to IpAddr=10.10.10.101 Port=62354 11/13/2012 20:14:18.636 (3589): 11/13/2012 20:14:18.636 (3589): Raw packet dump : 11/13/2012 20:14:18.636 (3589): 000: 05 80 00 14 97 44 72 ab b6 0f 09 29 83 86 6d fe |.....Dr....)..m.| 11/13/2012 20:14:18.636 (3589): 010: ac 11 be 84


|.... | 11/13/2012 20:14:18.636 (3589): --------------------------------------------------------- 11/13/2012 20:14:18.636 (3589): Packet containing 20 bytes successfully sent on local UDP port 37619 to target 10.10.10.101

Summary

This chapter has introduced the Steel Belted Radius basic configuration for authorizing a DHCP subscriber on the MX. It has also shown how to pass attributes from SBR back to the MX’s dynamic profile using VSAs in SBR and $junos variables in the MX, and has further attempt-ed to show the various logging points in both SBR and the MX, which can be useful in debugging configuration errors.

The Chapter 4 introduces RADIUS CoA and shows how the $junos variable within the MX can be modified using CoA.

Chapter 4

Basic CoA Setup Using SBR GUI

Current Session Table and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

CoA Packing Lists and Controlled Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

XML Tags in DeviceModels .xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Initiating a CoA from SBR Admin GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Testing the Configuration – Debug Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60

MX General-authentication-server Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63


This chapter describes setting up SBR to issue Change of Authorization requests to the MX. Change of Authorization (CoA) is defined in RFC 3576 and changes the traditional client-server model of RADIUS. A CoA is an unsolicited request from the RADIUS (server) to the MX (Client). CoA typically uses the attribute accounting-session-id to identify the session on the MX that needs the change. Along with the IP address of the MX, these two values can uniquely identify any session, even in networks with millions of active sessions.

After an access request is successful in SBR, it issues an access accept message back to the MX . The access accept message contains attri-butes that correspond to firewall filters that are applied to the subscrib-ers connection. After the MX applies the firewall filters, it issues a RADIUS accounting start message to SBR. This accounting start message builds a new session in SBR’s Current Session Table (CST). (The access request and access accept build what’s called a phantom session, and the accounting start converts the phantom to a real session). From the SBR log file in the previous chapter:

11/13/2012 20:14:18.635 (3589): Creating new CST record with Class attribute 11/13/2012 20:14:18.636 (3589): SessionDbc (INFO): UniqueSessionId is based on assigned IP address + 12 bytes of 0

This current session table contains attributes that were in the account-ing start, such as Framed-IP-Address, NAS-IP-Address, and Account-ing-Session-ID. The accounting-session-ID is a number generated by the MX to uniquely identify this session, and is stored in SBR’s current session table for use for purposes such as processing CoA requests.

Current Session Table and Attributes

SBR dynamically maintains a database of all active sessions in a table called the current session table (CST). In the standalone version of SBR, which is being used here, the table is not configurable, meaning the attributes being stored for each session are pre-defined at installa-tion time. In the cluster version of SBR, called the Session State Regis-trar (SSR), the CST schema is configurable and uses a version of MySQL cluster to build the CST. Regardless of whether it’s standalone or cluster, the relevant attributes needed in this book are stored in the CST. The standard set of RADIUS attributes includes User-Name, NAS-IP-Address, Acct-Session-ID, Framed-IP-Address, and others.

The CST is a table row per session, storing attributes received in Access Request and Accounting Start messages. When SBR processes an Access Request, it generates something called a Phantom Session Record. This phantom record includes attributes from the access

Chapter4:BasicCoASetupUsingSBRGUI 53

request, but fields not available, like acct-session-id, are listed as not available (n/a). This phantom record is short-lived, a default of 180 seconds, and is replaced by a session record when SBR receives the accounting start message related to the phantom. The 180-second lifespan is used to deal with SBR not receiving an accounting start in certain scenarios. It ensures that phantom records don’t create a problem over time.

The CST is an important source of information when issuing CoA commands. Returning to the SBR GUI, in the left hand navigation panel, select Current Sessions and then click on the Query Execution Query button. The default panel will search wildcard for user as selected in Select by User.

The session listed here is the session generated from the Chapter 3. To see the XML representation of this session, simply right click on the session and select copy and then paste into a word processor – the following output should be seen with all of the associated attributes:

<sessionResults> <sessionResult sequence="1"> <sessionData handle="0a0a0a33000000000000000000000000"> <attributes> <attribute name="User-Name" sequence="1" value="FOOBAR.0050.56BD.0035"/> <attribute name="NAS-Port" sequence="2" value="536875007"/> <attribute name="NAS-Port-Type" sequence="3" value="15"/> <attribute name="Framed-IP-Address" sequence="4" value="10.10.10.51"/> <attribute name="Acct-Session-Id" sequence="5" value="14"/> <attribute name="NAS-IP-Address" sequence="6" value="10.10.10.101"/> <attribute name="NAS-Identifier" sequence="7" value="MX"/> </attributes> </sessionData> <sessionRequest/> <deviceResults> <deviceResult device="MX" sequence="1"> <deviceRequest/> <deviceResponse resultCode="00010100" resultMessage="request completed successfully"/> </deviceResult> </deviceResults> <sessionResponse resultCode="00010100" resultMessage="request completed successfully"/> </sessionResult> </sessionResults>

On the right-hand side of the GUI, there are action buttons, three of which are labeled Boost10M, Boost5M, and Boost2M. These buttons are used to invoke a CoA from the GUI panel. Defining these buttons is covered in the next section.


CoA Packing Lists and Controlled Devices

The first step in configuring SBR to issue CoA commands is to define the packing list for each CoA action. The examples being used are our three firewall filters named police-2M, police-5M, and police-10M. These firewall filter names correspond to RADIUS Vendor Specific Attributes (VSAs) called unisphere-ingress-policy-name and unisphere-egress-policy-name. For this book, CoA simply changes the unisphere-egress-policy-name to one of the firewall filters and the CoA actions will be called Boost10M, Boost5M, and Boost2M. These actions are what cause the GUI in the previous section to display the buttons to generate the CoA.

A packing list that is specific for each action on the MX needs to be defined. Packing lists are defined in SBR in a file called deviceModels.xml, which builds the packing lists for each RADIUS client (called a controlled device) as well as each action to be taken (Boost10M, Boost5M, etc.) for each RADIUS client. The packing list is merely a list of attributes that need to be sent to invoke the CoA. SBR refers to devices defined in the deviceModels.xml file as controlled devices. Controlled devices that are defined in deviceModels.xml, and that have been configured as a RADIUS client in the SBR admin GUI, will be available for issuing CoAs.

The default deviceModels.xml file contains a number of sample RADIUS clients along with some example CoA actions. The following file snippet shows the RADIUS clients configured in the SBR Radius Client panel Unisphere MX with Junos v11.2, from Chapter 3:

<controlledDeviceModel id="Unisphere MX with JUNOS v11.2" vendor="juniper" model="Unisphere MX with JUNOS v11.2" dictiona ry="unisphereMX11-2.dct"> <RADIUSPorts>  <RADIUSPort name="RFC3576" description="Dynamic Authorization via RADIUS" port="3799"/> </RADIUSPorts> <actions> <action name="query"> <localSessionQuery description="return local session data"/> </action> <action name="disconnect"> <RADIUSRequest description="RFC 3576 Disconnect Message" code="DM" portName="RFC3576"> <attributes> <requiredAttribute name="Acct-Session-Id"/> </attributes> <onSuccess>  <sessionStop description="Simulated Session Stop"/> </onSuccess> <onFailure>  <sessionStop description="Cleaning Session Database"/> </onFailure> <onTimeout/> </RADIUSRequest> </action> <action name="Boost10M" description="boost sub to 10M down"> <RADIUSRequest code="CoA" portName="RFC3576"> <attributes> <requiredAttribute name="Acct-Session-Id"/> <overrideAttribute name="Unisphere-egress-policy-name" value="police-10M"/> </attributes> </RADIUSRequest> </action> <action name="Boost5M" description="boost sub to 5M down"> <RADIUSRequest code="CoA" portName="RFC3576"> <attributes> <requiredAttribute name="Acct-Session-Id"/> <overrideAttribute name="Unisphere-egress-policy-name" value="police-5M"/> </attributes> </RADIUSRequest> </action> <action name="Boost2M" description="boost sub to 2M down"> <RADIUSRequest code="CoA" portName="RFC3576"> <attributes> <requiredAttribute name="Acct-Session-Id"/> <overrideAttribute name="Unisphere-egress-policy-name" value="police-2M"/> </attributes> </RADIUSRequest> </action> </actions>

You can see in this file snippet that the XML begins with the controlled device name and Make or Model, which corresponds to what was previously configured for the MX in SBR’s Add RADIUS Clients. Each device that needs CoA support must have definitions in this file. Next, you can see the port used for CoA – 3799 is defined. This can be changed per controlled device, but just make sure both sides are changed. (Currently there is no way to change the CoA port on the MX – it defaults to 3799.) The last parts of the controlled device configuration are the actions to be performed on this device.

The actions, which are defined, appear in the SBR GUI when Current Session is selected, and the actions of interest here are Boost10M, Boost5M, and Boost2M. Each action should be self explanatory, and


should only require two attributes: the Acct-Session-ID and the Unisphere-egress-policy-name. The attributes are tagged with require-dAttribute and overrideAttribute. There is another tag called defaultAttribute, which is not used in this example, but is important to understand. The following section will explain the attribute tags along with how SBR manages sessions and CoA.

For this book’s lab, build the deviceModels.xml with the above actions Boost10M, Boost5M, and Boost2M in the packing list for Unisphere MX with JUNOS v11.2.

After the deviceModels.xml file is edited, the SBR and the SBR admin GUI need to be restarted to load the new configurations.

XML Tags in DeviceModels.xml

The following is a complete packing list required for the MX to change a unique subscriber session to firewall filter police-5M on the egress:

<action name="Boost5M" description="boost sub to 5M down"> <RADIUSRequest code="CoA" portName="RFC3576"> <attributes> <requiredAttribute name="Acct-Session-Id"/> <overrideAttribute name="Unisphere-egress-policy-name" value="police-5M"/> </attributes> </RADIUSRequest> </action>

The XML tags are interpreted by the CoA subsystem within SBR to process the CoA. The first tag, action name, is used as a display name and a request action name when using the XML over https API in Chapter 5.

RADIUSRequest code in this packing list is CoA, it can also be DM for disconnect, or POD for Cisco’s Packet of Disconnect.

The attributes section is where you define the attributes that need to be sent, but more importantly, SBR should get the value from there. When SBR processes a request for CoA, the attributes can be sent in the request, they can come from the current session table, or they can be in both when it is necessary to specify which value to use. The term requiredAttribute must either be included in the request, in static value, or found in the CST. In our example, the attribute must be found in the CST since no value is specified.

� overrideAttribute specifies that SBR must use this value in the example police-5M. This must be specified as override since the


CST may have the previous policy-name in its CST, and it needs to be overridden with police-5M.

� defaultAttribute is the final tag that we are not using in the example. This tag is used when you don’t want a request to fail if a value is not found in the CST or in the request. SBR would only substitute the value in defaultAttribute for the request if this is the case.

Other tags are that can be used in packing lists are documented in the SBR Administrator’s Guide, but for our basic CoA and DM the above should be sufficient.

NOTE To send the CoA requests, SBR must know the IP address of the MX, but this information is automatically taken from the CST so it does not need to be defined in deviceModels.xml.

Initiating a CoA from SBR Admin GUI

Now that the deviceModels.xml file is configured (as described in this chapter) the SBR Admin GUI should have the action buttons config-ured in the action name tag:

action name="Boost5M"

At this point you should close the SBR GUI, quit, and then restart SBR with the ./sbrd restart and then launch the GUI again from http://<SBR-IP-address>:1812. If the deviceModels.xml file was configured correctly, the following should be seen in the panel for your current session:


Launch a query for sessions as shown here, and the right hand panel should show all actions available for sessions including the new Boost actions.

Before launching the CoA, let’s view the session and associated firewall filters on the MX:

root@Camlab> show subscribers Interface IP Address/VLAN ID User Name LS:RI demux0.1073741828 10.10.10.53 foobar.0050.56bd.0035 default:default root@Camlab> show firewall Filter: __default_bpdu_filter__ Filter: police-2M-demux0.1073741828-in Policers: Name Bytes Packets 2M-all-demux0.1073741828-in 0 0Filter: police-2M-demux0.1073741828-out Policers: Name Bytes Packets 2M-all-demux0.1073741828-out 0 0root@Camlab>

The show command shows the session is active along with the RADI-US-initiated firewall filters police-2M.

Now let’s initiate a Boost10M CoA. In the SBR GUI simply highlight the session and click on Boost10M, and the following window should appear.

mailto:root@Camlab

mailto:root@Camlab

mailto:root@Camlab


Click on the Request Execution Boost10M button, and if all is good, the resulting message – request completed successfully – should appear as follows:

As a final check, go back to the MX, and look at the firewall to see if the police-10M filter has been set on the egress. Mission accomplished.

root@Camlab> show firewall Filter: __default_bpdu_filter__ Filter: police-2M-demux0.1073741828-in Policers: Name Bytes Packets 2M-all-demux0.1073741828-in 0 0

mailto:root@Camlab


Filter: police-10M-demux0.1073741828-out Policers: Name Bytes Packets 10M-all-demux0.1073741828-out 0 0root@Camlab>

Testing the Configuration – Debug Logs

To debug the configuration, let’s start with the logs on SBR. Log files are located in /opt/JNPRsbr/RADIUS and are named YYYYMMDD.log. Tracking today’s file on success would show the following output (which has been broken up for an easier debug).

The first part of the transaction log is the request that comes from the SBR Admin GUI. This contains a Funk-Session-Handle, which is an SBR-unique session identifier attribute hidden from normal view. This simply identifies the session highlighted in the admin GUI, and tells SBR which session to look up in the CST:

11/06/2012 20:00:21.110 (2140): ++++++ Request received from user ++++++ 11/06/2012 20:00:21.110 (2140): Request 11/06/2012 20:00:21.110 (2140): (String ) Funk-Session-Handle = '0a0a0a35000000000000000000000000' (32 bytes) 11/06/2012 20:00:21.110 (2140): (String ) Acct-Session-Id = '' (0 bytes) 11/06/2012 20:00:21.110 (2140): ------ End Request received from user ------

This next log section shows what SBR has retrieved from the CST – all of the attributes associated with the session. As described earlier, the only attribute needed for the packing list is the Acct-Session-ID, but SBR also needs to know the NAS-IP-Address, so it can finally send the CoA along with the shared secret for this NAS:

11/06/2012 20:00:21.110 (2140): 11/06/2012 20:00:21.110 (2140): 11/06/2012 20:00:21.111 (2140): 11/06/2012 20:00:21.111 (2140): ++++++ Request for individual session ++++++ 11/06/2012 20:00:21.111 (2140): Request 11/06/2012 20:00:21.111 (2140): (String ) User-Name = 'FOOBAR.0050.56BD.0035' (21 bytes) 11/06/2012 20:00:21.111 (2140): (Integer32 ) NAS-Port = '536875007' (4 bytes) 11/06/2012 20:00:21.111 (2140): (Integer32 ) NAS-Port-Type = '15' (4 bytes) 11/06/2012 20:00:21.111 (2140): (IP Address) Framed-IP-Address = '10.10.10.53' (4 bytes) 11/06/2012 20:00:21.111 (2140): (String ) Acct-Session-Id = '16' (2 bytes) 11/06/2012 20:00:21.111 (2140): (IP Address) NAS-IP-Address = '10.10.10.101' (4 bytes) 11/06/2012 20:00:21.111 (2140): (String ) NAS-Identifier = 'MX' (2 bytes) 11/06/2012 20:00:21.111 (2140): ------ End Request for individual session ------ 11/06/2012 20:00:21.111 (2140): 11/06/2012 20:00:21.111 (2140): 11/06/2012 20:00:21.111 (2140):

mailto:root@Camlab


This next log shows the actual request with the Acct-Session-ID filled in from the previous log section, along with the override attribute Unishphere-Egress-Policy-Name set to police-10M:

11/06/2012 20:00:21.111 (2140): ++++++ Request sent to device ++++++ 11/06/2012 20:00:21.111 (2140): Change of Authorization Request Packet 11/06/2012 20:00:21.111 (2140): (String ) Acct-Session-Id = '16' (2 bytes) 11/06/2012 20:00:21.111 (2140): (String ) Unisphere-Egress-Policy-Name = 'police-10M' (10 bytes) 11/06/2012 20:00:21.111 (2140): ------ End Request sent to device ------ 11/06/2012 20:00:21.111 (2140): 11/06/2012 20:00:21.111 (2140): 11/06/2012 20:00:21.111 (2140): started RADIUS request against target 'MX:RFC3576' 11/06/2012 20:00:21.111 (2121): formatting proxy request for target number 0 11/06/2012 20:00:21.111 (2121): proxy work has next scheduled send at time 1352250024 11/06/2012 20:00:21.111 (2121): calculated delay is 3000 11/06/2012 20:00:21.111 (2121): proxy target sequence processing: 11/06/2012 20:00:21.111 (2121): considering reference 0 = target 0 11/06/2012 20:00:21.111 (2121): considering sending to target 0 11/06/2012 20:00:21.111 (2121): not yet fast fail, wait for response from this target 11/06/2012 20:00:21.111 (2121): 11/06/2012 20:00:21.261 (10122): received proxy response at time 1352250021 11/06/2012 20:00:21.261 (2121):

And this final log output shows the results returned from the MX: Transaction Result = session control request successful.

11/06/2012 20:00:21.261 (2121): ++++++ Response received from device ++++++ 11/06/2012 20:00:21.261 (2121): Transaction Result = session control request successful 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): ------ End Response received from device ------ 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): ++++++ Response for individual session ++++++ 11/06/2012 20:00:21.261 (2121): Transaction Result = session control request successful 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): ------ End Response for individual session ------ 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): Action 'CoA' was completed against device 'MX' with result: 'session control request successful'. 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): ++++++ Begin Session Results ++++++ 11/06/2012 20:00:21.261 (2121): Result = 'session control request successful' 11/06/2012 20:00:21.261 (2121): Device 'MX' 11/06/2012 20:00:21.261 (2121): Attributes:


11/06/2012 20:00:21.261 (2121): ------ End Session Results ------ 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): ++++++ Begin Device Results ++++++ 11/06/2012 20:00:21.261 (2121): Cached Session Attributes: 11/06/2012 20:00:21.261 (2121): User-Name = 'FOOBAR.0050.56BD.0035' 11/06/2012 20:00:21.261 (2121): NAS-Port = '536875007' 11/06/2012 20:00:21.261 (2121): NAS-Port-Type = '15' 11/06/2012 20:00:21.261 (2121): Framed-IP-Address = '10.10.10.53' 11/06/2012 20:00:21.261 (2121): Acct-Session-Id = '16' 11/06/2012 20:00:21.261 (2121): NAS-IP-Address = '10.10.10.101' 11/06/2012 20:00:21.261 (2121): NAS-Identifier = 'MX' 11/06/2012 20:00:21.261 (2121): Action 'CoA' Attributes: 11/06/2012 20:00:21.261 (2121): Required: <requiredAttribute name="Acct-Session-Id" copyFrom="Acct-Session-Id"/> 11/06/2012 20:00:21.261 (2121): Override: <overrideAttribute name="Unisphere-egress-policy-name" copyFrom="Unisphere-egress-policy-name" value="police-10M"/> 11/06/2012 20:00:21.261 (2121): Device Response Attributes: 11/06/2012 20:00:21.261 (2121): ------ End Device Results ------ 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): ++++++ Response sent to user ++++++ 11/06/2012 20:00:21.261 (2121): Transaction Result = session control request successful 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): ------ End Response sent to user ------ 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.261 (2121): 11/06/2012 20:00:21.262 (2207): MCB notification in admin session; callback 11/06/2012 20:00:21.262 (2207): resuming stream

MX General-authentication-server Log

The next step in debugging is to look at the logs in the MX, once again using the general-authentication-server log from Chapter 3. The general-authentication-server log shows receipt of the CoA message and the attributes present in the message.

root@Camlab> monitor start authd *** authd *** Nov 6 20:26:24 jnp_RADIUS_disconnect_udp_callback parse AVP in disconnect req datagram_len 42 req_attributes_len 22 current_offset 0 Nov 6 20:26:24 ============ CoA/Disconnect Callback =================Nov 6 20:26:24 dyn_req_disconnect_cb attributes remote_addr:(10.10.10.102) remote_port:(33991), rtbl_idx:(0) Nov 6 20:26:24 received in AVP disconnect req type:44 val:16 len:2 Nov 6 20:26:24 received in AVP disconnect req type:26 val: len:16 Nov 6 20:26:24 authd_map_ssh_attribute No Mapping for attribute :26 Nov 6 20:26:24 authd_extract_RADIUS_disconnect_avps Unhandled attribute Nov 6 20:26:24 authd_verify_request_context: authenticating context LS: <default>;

mailto:root@Camlab


RI: <default> Nov 6 20:26:24 RADIUS-access-reject: Egress-Policy-Name (Juniper-ERX-VSA) received: police-10M Nov 6 20:26:24 dyn_req_disconnect_cb server_id (10.10.10.102) (10.10.10.102) port(33991) (33991) cookie :4 Nov 6 20:26:24 retrieveUndoInformation: junos-output-filter police-10M Nov 6 20:26:24 ====== Dynamic Service Request ======= Nov 6 20:26:24 setDynamicProfileUpdateFailCause: dynamicProfileUpdateResult 1 Nov 6 20:26:24 AuthFsm::current state=AuthStateActive(9) event=35 astEntry=0x8c6042c aaa msg=0 Nov 6 20:26:24 Auth-FSM: Updating attributes in the client's dynamic profile for session-id:16 Nov 6 20:26:24 updateSdbDynamicAttributes: do: name: junos-output-filter value: police-10M encoding: 0 Nov 6 20:26:24 Instantiating a Dynamic-Service:IPDemux for service session:16 for subscriber:16 config-bits:0x80007 0 0 0 0 Nov 6 20:26:24 Auth-FSM: GRES-Mirror for session-id:16 state:AuthProfileUpdateWait(11) Nov 6 20:26:24 Dynamic Service Handler Nov 6 20:26:24 authd_auth_aaa_msg_destroy Nov 6 20:26:24 authd_auth_aaa_msg_destructauth_aaa_msg: 0x8b265c4 Nov 6 20:26:24 dyn_req_disconnect_cb dyn_result :1 Nov 6 20:26:24 smm_response_handle_callbackNov 6 20:26:24 Ack/Nack from dyn-prof-lib for session: 16. result-code:0 Nov 6 20:26:24 authFsmExecute: AUTH_PROFILE_UPDATE_ACK/NAK Nov 6 20:26:24 AuthFsm::current state=AuthProfileUpdateWait(11) event=36 astEntry=0x8c6042c aaa msg=0 Nov 6 20:26:24 Auth-FSM: Handle client's dynamic profile update Ack. session-id:16 Nov 6 20:26:24 Auth-FSM: GRES-Mirror for session-id:16 state:AuthStateActive(9) Nov 6 20:26:24 Sending Service Processed Response Nov 6 20:26:24 ====== Dynamic Service Response ======= Nov 6 20:26:24 smmResponseHandler 0 Nov 6 20:26:24 authd_build_aaa_request: Found dynRequest with cause 0 Nov 6 20:26:24 authd_dynreq_async_disconnect_send username:(foobar.0050.56bd.0035) result:(1) Nov 6 20:26:24 cookie:(4) server_id:(10.10.10.102) port(33991)remote_addr:(10.10.10.102) remote_port:(33991) Nov 6 20:26:24 authd_auth_aaa_msg_destroy Nov 6 20:26:24 authd_auth_aaa_msg_destructauth_aaa_msg: 0x8b265c4 Nov 6 20:26:24 cleanServiceList: numRequests 0 Nov 6 20:26:24 ~DynamicRequestEntry

Summary

This chapter covered the SBR configuration required to initiate CoA commands to change firewall filters on active sessions. The concept of packing lists of attributes needed for firewall filter changes, the XML format of deviceModels.xml, and the tagging of attributes within the file were all detailed.


Also examined was how SBR retrieves the information needed to fill out a CoA request from both the deviceModels.xml file and from the current session table. Finally, it was noted that SBR and MX logging can be helpful in debugging configuration errors.

With those concepts understood, let’s put it all to use with self-service portal that can now be developed using the SBR’s XML over an HTTPS API to allow an external web host to issue the same CoA commands as the SBR GUI.

Chapter 5

Simple Web Portal

Loading XAMPP and the Startup of Apache on Windows . . . . . . . . . . . . . . 67

Scripting the Self Service Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

radioButton .php and XML Envelopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Testing the Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

SBR Logs for XML API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79


This chapter introduces you to how to script a simple self-service portal in HTML and PHP that allows the subscriber to change the firewall filter on their connection using the XML over HTTPS API within SBR.

If you need to expand its usage, any COA attributes, such as scheduler maps, firewall filters, IGMP, and IPv6, can be changed. The list of supported vendor-specific attributes for use with CoA on the MX are in Table 5.1.

Table 5.1 Supported Juniper Networks Vendor-specific Attributes (VSAs) for Use with CoA

VSA Attribute

Ingress-Policy-Name Input policy name to apply to client interface.

Egress-Policy-Name Output policy name to apply to client interface

IGMP-Enable Enable or disable IGMP on a client interface

LI-Action Traffic mirroring action

Med-Dev- Handle Link to which traffic mirroring is applied

Service-Statistics Enable or disable statistics for the service

IGMP-Access-Group-Name Access list to use for the group filter

MP-Access-Source-Group-Name Access list to use for the source-group filter

MLD-Access-Group-Name Access list to use for the group filter

MLD-Access-Source-Group-Name Access list to use for the source-group filter

MLD-Version MLD protocol version

IGMP-Version IGMP protocol version

IGMP-Immediate-Leave IGMP immediate leave

MLD-Immediate-Leave MLD immediate leave

IPv6-Ingress-Policy-Name Input policy to apply to a user IPv6 interface

IPv6-Egress-Policy-Name Output policy to apply to a user IPv6 interface

CoS-Shaping-Pmt-Type CoS traffic shaping parameter type

Interface-Set-Name Interface set to apply to the dynamic profile

Service-Interim-Acct-Interval Amount of time between accounting interims for this service

CoS-Scheduler-Pmt-Type CoS scheduler parameter types

In this book, the focus is on changing the egress firewall filter, however, if you examine the attribute list in Table 5.1, it’s clear that many other actions can be performed. For the use case for this book, the subscriber connects to the portal and the portal uses the IP address of the subscrib-er as the search criteria for the session in SBR. The portal has a simple radio button selection for 2 M, 5M, or 10M service, as defined in device-Models.xml (Chapter 4). Selecting the radio button will issue the XML request to SBR using the API. As you can see, the web portal is very simple:

Chapter5:SimpleWebPortal 67

Loading XAMPP and the Startup of Apache on Windows

For this example, you will be loading XAMPP, from Apache Friends, which is a packaging of the Apache web server, along with Perl, PHP, and MySQL, and other useful tools like Filezilla. This is sometimes called a LAMP server, (Linux, Apache, MySQL, and PHP), but in this case only the web server and PHP are used.

Using your favorite web browser, surf to http://www.apachefriends.org/en/xampp.html and download the distribution for your system. Windows is being used in this book with the 1.8.1 release of XAMPP (highly recom-mended since no modifications in the configuration are needed). Earlier versions of XAMPP do not enable CURL (Client URL) by default, which is used to make the call to SBR. Follow the Wizard setup and you should see the following:

http://www.apachefriends.org/en/xampp.html

http://www.apachefriends.org/en/xampp.html


After the installation is complete, XAMPP comes with a control panel that must be started. The control panel allows quick and easy restarting of the Apache service. To test Apache quickly, click on Start, and then using your browser, type localhost in the Navigation Toolbar, and the XAMPP startup window should appear.

NOTE If using a Windows machine, sometimes the Windows Web Server IIS is enabled, preventing Apache from starting. Only one process can use port 80 at a time and the IIS needs to be disabled to allow Apache to start.


NOTE Firewalls can also block Apache – if there’s issues starting or communi-cating with Apache, you might want to check here.

MORE? If you still have issues getting Apache to run, searching for your problem in the XAMPP FAQ often can resolve it: http://www.apache-friends.org/en/faq-xampp.html.

Scripting the Self Service Portal

Our self service portal web page shown previously is shown here in HTML and PHP, and called order.php:

order.php file<html><head><title>Self Service Portal</title></head><body><body style="background-color:lightgrey;"><div align="center"><FORM name="form" Method="Post" ACTION="radioButton.php"<br><br>

<center><img src="img/juniperlogo.jpg"></center><h1 style="font size 200%" align="center">Self Service Portal</h1><br><?php//header ('Content-type: text/xml');$ip = $_SERVER['REMOTE_ADDR'];$hostaddress = gethostbyaddr($ip);print "<strong>Hello:</strong><br />\n";print "$ip<br /><br />\n";print "<strong>Also Known as:</strong><br />\n";print "$hostaddress<br /><br />\n";?><h2 style="font size 125%" align="center">Please select your NEW service</h2><input type="radio" align="abdmiddle" name="group1" value="Bronze"> Basic 2M Service<br><input type="radio" align="absmiddle" name="group1" value="Silver" checked> Premium 5M Service<br><input type="radio" align="absmiddle" name="group1" value="Gold"> Ultimate 10M Service<br><br><input type="submit" value="submit"><br><br><br></div></FORM></body></html>

XAMPP, by default, is installed on a Windows machine directly on the c: drive in c:\xampp. Within the xampp directory is a directory called htdocs, and htdocs is the directory that Apache looks in for web pages to be viewed by a browser. Go inside htdocs, create another directory called

http://www.apachefriends.org/en/faq-xampp.html

http://www.apachefriends.org/en/faq-xampp.html


xampp, and place the order.php file in there, so: c:\xampp\htdocs\xampp\order.php. The url for this web page, becomes http://<ipaddress>/xampp/order.php since apache defaults to htdocs. To test on the local machine, try http://localhost/xampp/order.php.

To make order.php work, a few lines in the script may need explanation:<center><img src="img/juniperlogo.jpg"></center>

This line requires a file named juniperlogo.jpg to be in \xampp\htdocs\xampp\img. Of course, any jpeg file works here, other logos, pictures of cats, or anything, just make sure the file name matches exactly. $ip = $_SERVER['REMOTE_ADDR'];$hostaddress = gethostbyaddr($ip);

The first line is used to set the $ip variable equal to the IP address of the client coming to the web page, and the second line is the host name set to $hostaddress, if available. These are displayed on the web page using:

print "<strong>Hello:</strong><br />\n";print "$ip<br /><br />\n";print "<strong>Also Known as:</strong><br />\n";print "$hostaddress<br /><br />\n";?>

Finally, the order.php file is just the web page, including the line:

<FORM name="form" Method="Post" ACTION="radioButton.php"

This calls another script called radioButton.php, where the actual XML over HTTPS API call is made. This ACTION sends the value associated with the selected radio button to the radioButton.php script. The values being Bronze, Silver or Gold, which equal firewall filters police-2M, police-5M, and police-10M .

<input type="radio" align="abdmiddle" name="group1" value="Bronze"> Basic 2M Service<br><input type="radio" align="absmiddle" name="group1" value="Silver" checked> Premium 5M Service<br><input type="radio" align="absmiddle" name="group1" value="Gold"> Ultimate 10M Service<br><br><input type="submit" value="submit"><br><br><br>

radioButton.php and XML Envelopes

The API within SBR that handles CoA expects to see an XML envelope posted to https://<SBR_IP_Address>:1813/scs/request. An XML envelope is required for each of the actions defined in deviceModels.xml - Boost2M, Boost5M, and Boost10M. For simplicity, the envelopes are defined as


variables and are part of radioButton.php. The file could be simplified, but for ease of reading, they are listed individually. An XML envelope for the API must be in the following format:<envelope><header /><body><request action='Boost10M'><attributes><attribute enabled='true' name='Framed-IP-Address' value='$ip'/></attributes></request></body></envelope>

The envelope contains the request action tag, Boost10M, which is defined in deviceModels.xml in SBR. The only attribute that needs to be passed to the API is Framed-IP-Address, which is equal to the IP address of the client connecting to the portal. The API is smart enough, since the required attributes were defined in deviceModels.xml, to look up the session attributes for the Framed-IP-Address. For reference, the Boost10M action in deviceModels.xmls is listed:

<action name="Boost10M" description="boost sub to 10M down"> <RADIUSRequest code="CoA" portName="RFC3576"> <attributes> <requiredAttribute name="Acct-Session-Id"/> <overrideAttribute name="Unisphere-egress-policy-name" value="police-10M"/> </attributes> </RADIUSRequest> </action>

The tag requiredAttribute tells SBR that it must look up the Acct-Session-ID in the current session table for the Framed-IP-Address contained in the request. If it’s not found, it will simply fail. If it is found, SBR populates the CoA request with the Acct-Session-ID and sends it to the NAS-IP-Address, which is also found in the SBR session table.

The radioButton.php script also needs to be placed at the following location: c:\xampp\htdocs\xampp\radioButton.php: it’s important to note that there isn’t any error handling or corner cases in this script. It’s just a simple PHP script:

radioButton.php

<?PHP//read input from order.php and print

$selected_radio=$_POST['group1'];print $selected_radio;


//header ('Content-type: text/xml');//set $ip variable to ip address of client

$ip = $_SERVER['REMOTE_ADDR'];

//set XML envelopes to be sent to SBR$Boost10M="<envelope><header /><body><request action='Boost10M'><attributes><attribute enabled='true' name='Framed-IP-Address' value='$ip'/></attributes></request></body></envelope>";

$Boost2M="<envelope><header /><body><request action='Boost2M'><attributes><attribute name='Framed-IP-Address' value='$ip'/></attributes></request></body></envelope>";

$Boost5M="<envelope><header /><body><request action='Boost5M'><attributes><attribute name='Framed-IP-Address' value='$ip'/></attributes></request></body></envelope>";

//secure http routine

function getfromssr($xmlrequest) {//Initialize handle and set options – username and password for root go here. $username = 'root'; $password = 'xxx'; $ch = curl_init(); // ensure IP Address of SBR is in URL and port is set to 1813 curl_setopt($ch, CURLOPT_URL, 'https://10.10.10.102/scs/request/'); curl_setopt($ch, CURLOPT_PORT, 1813); curl_setopt($ch, CURLOPT_USERPWD, $username.':'.$password); curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_BASIC); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);


curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_TIMEOUT, 15); curl_setopt($ch, CURLOPT_POSTFIELDS, $xmlrequest); //Execute the request

$result = curl_exec($ch);

//Close the handlecurl_close($ch);}// executes the appropriate XML based on radiobutton

if ($selected_radio=="Gold"){ $fromssr = getfromssr($Boost10M);}elseif ($selected_radio=="Silver"){ $fromssr = getfromssr($Boost5M);}elseif ($selected_radio=="Bronze"){ $fromssr = getfromssr($Boost2M);}

{ echo "<br><strong>Please Enjoy your new service</strong>";}

?>

The curl code function $getfromssr is a simple HTTPS connect, with username and password, to the SBR host, and then POSTing the XML envelope selected by the if and elseif statements. The XML envelopes contain the action name and the Framed-IP-Address of the client requesting it. That’s all that’s required by the API in SBR. To fulfill the action, SBR takes the Framed-IP-Address and searches the session table for the NAS-IP-Address along with the Acct-Session-ID corresponding to the Framed-IP-Address.

Testing the Portal

Now that the HTML and PHP code are loaded onto the Apache server, the client PC should be able to connect to the self service portal web page. Let’s go to http://<Apache_IP_Address>/xampp/order.php.


That should bring up the main self-service portal:

If you select the Ultimate 10M Service radio button and submit – the resulting page should be as follows:


The radiobutton.php script will print the selected radio button from the order.php page and also print in bold, Please Enjoy your new service. Very cool.

SBR Logs for XML API

When using the XML API, SBR logs will show a significant amount of information regarding the transaction – the log outputs from SBR have been broken up with the first piece of information being the connection and incoming XML envelope. The POST, which is received at SBR, is shown in the raw request along with the root user authentication.

NOTE If using root is not an option— some installations have strict policies on root users,—you can use a different username. You do that by defin-ing another administrator in the SBR admin GUI with superuser privileges, and then using that user’s credentials in the getfromssr routine:

12/06/2012 17:09:53.356 (2196): MCI notification in admin session; incoming session 12/06/2012 17:09:53.356 (2196): MDI notification in admin session; data is available 12/06/2012 17:09:53.356 (2196): admin interface incoming raw request (378 bytes): 12/06/2012 17:09:53.356 (2196): 000: 504f5354 202f7363 732f7265 71756573 |POST /scs/reques| 12/06/2012 17:09:53.356 (2196): 010: 742f2048 5454502f 312e310d 0a417574 |t/ HTTP/1.1..Aut| 12/06/2012 17:09:53.356 (2196): 020: 686f7269 7a617469 6f6e3a20 42617369 |horization: Basi| 12/06/2012 17:09:53.356 (2196): 030: 6320636d 39766444 70445957 31735957 |c cm9vdDpDYW1sYW| 12/06/2012 17:09:53.356 (2196): 040: 49784d6a 4d3d0d0a 486f7374 3a203130 |IxMjM=..


Host: 10| 12/06/2012 17:09:53.356 (2196): 050: 2e31302e 31302e31 30323a31 3831330d |.10.10.102:1813.| 12/06/2012 17:09:53.356 (2196): 060: 0a416363 6570743a 202a2f2a 0d0a436f |.Accept: */*..Co| 12/06/2012 17:09:53.356 (2196): 070: 6e74656e 742d4c65 6e677468 3a203139 |ntent-Length: 19| 12/06/2012 17:09:53.356 (2196): 080: 360d0a43 6f6e7465 6e742d54 7970653a |6..Content-Type:| 12/06/2012 17:09:53.356 (2196): 090: 20617070 6c696361 74696f6e 2f782d77 | application/x-w| 12/06/2012 17:09:53.356 (2196): 0a0: 77772d66 6f726d2d 75726c65 6e636f64 |ww-form-urlencod| 12/06/2012 17:09:53.356 (2196): 0b0: 65640d0a 0d0a3c65 6e76656c 6f70653e |ed....<envelope>| 12/06/2012 17:09:53.356 (2196): 0c0: 0d0a3c68 65616465 72202f3e 0d0a3c62 |..<header />..<b| 12/06/2012 17:09:53.356 (2196): 0d0: 6f64793e 0d0a3c72 65717565 73742061 |ody>..<request a| 12/06/2012 17:09:53.356 (2196): 0e0: 6374696f 6e3d2742 6f6f7374 31304d27 |ction='Boost10M'| 12/06/2012 17:09:53.356 (2196): 0f0: 3e0d0a3c 61747472 69627574 65733e0d |>..<attributes>.| 12/06/2012 17:09:53.356 (2196): 100: 0a3c6174 74726962 75746520 656e6162 |.<attribute enab| 12/06/2012 17:09:53.356 (2196): 110: 6c65643d 27747275 6527206e 616d653d |led='true' name=| 12/06/2012 17:09:53.356 (2196): 120: 27467261 6d65642d 49502d41 64647265 |'Framed-IP-Addre| 12/06/2012 17:09:53.356 (2196): 130: 73732720 76616c75 653d2731 302e3130 |ss' value='10.10| 12/06/2012 17:09:53.356 (2196): 140: 2e31302e 3531272f 3e0d0a3c 2f617474 |.10.51'/>..</att| 12/06/2012 17:09:53.356 (2196): 150: 72696275 7465733e 0d0a3c2f 72657175 |ributes>..</requ| 12/06/2012 17:09:53.356 (2196): 160: 6573743e 0d0a3c2f 626f6479 3e0d0a3c |est>..</body>..<| 12/06/2012 17:09:53.356 (2196): 170: 2f656e76 656c6f70 653e |/envelope> | 12/06/2012 17:09:53.356 (2196): 12/06/2012 17:09:53.356 (2196): admin interface recognized request 12/06/2012 17:09:53.376 (2196): admin session authenticated; user is 'root' 12/06/2012 17:09:53.376 (2196): admin session authenticated; user is in group 'root' 12/06/2012 17:09:53.376 (2196): admin session authenticated; user is in group 'root' 12/06/2012 17:09:53.376 (2196): admin session authenticated; user is in group 'bin' 12/06/2012 17:09:53.376 (2196): admin session authenticated; user is in group 'daemon' 12/06/2012 17:09:53.376 (2196): admin session authenticated; user is in group 'sys' 12/06/2012 17:09:53.376 (2196): admin session authenticated; user is in group 'adm' 12/06/2012 17:09:53.376 (2196): admin session authenticated; user is in group 'disk' 12/06/2012 17:09:53.376 (2196): admin session authenticated; user is in group 'wheel' 12/06/2012 17:09:53.376 (2196): user 'root' connected to admin interface 12/06/2012 17:09:53.376 (2196): admin session assigning access level 'SuperAdmin' to user 'root' 12/06/2012 17:09:53.376 (2196): found POST target resource at URI '/scs/request/'


12/06/2012 17:09:53.376 (2196): pausing stream 12/06/2012 17:09:53.377 (2104): 12/06/2012 17:09:53.377 (2104): ++++++ Request received from user ++++++ 12/06/2012 17:09:53.377 (2104): Request 12/06/2012 17:09:53.377 (2104): (IP Address) Framed-IP-Address = '10.10.10.51' (4 bytes) 12/06/2012 17:09:53.377 (2104): ------ End Request received from user ------

In the raw request, the action Boost10M is identified along with the actual request for Framed-IP-Address 10.10.10.51. The next section of the log shows that the API looks up the attributes associated with the Framed-IP-Address in the current session table:

12/06/2012 17:09:53.377 (2104): ++++++ Request for individual session ++++++ 12/06/2012 17:09:53.377 (2104): Request 12/06/2012 17:09:53.377 (2104): (String ) User-Name = 'FOOBAR.0050.56BD.0035' (21 bytes) 12/06/2012 17:09:53.377 (2104): (Integer32 ) NAS-Port = '536875007' (4 bytes) 12/06/2012 17:09:53.377 (2104): (Integer32 ) NAS-Port-Type = '15' (4 bytes) 12/06/2012 17:09:53.377 (2104): (IP Address) Framed-IP-Address = '10.10.10.51' (4 bytes) 12/06/2012 17:09:53.377 (2104): (String ) Acct-Session-Id = '48' (2 bytes) 12/06/2012 17:09:53.377 (2104): (IP Address) NAS-IP-Address = '10.10.10.101' (4 bytes) 12/06/2012 17:09:53.377 (2104): (String ) NAS-Identifier = 'MX' (2 bytes) 12/06/2012 17:09:53.377 (2104): ------ End Request for individual session ------

Once SBR has looked up the session and can resolve the Acct-Session-Id, it processes the CoA message using the packing list in deviceMod-els.xml. And you’ll see in the end, that the request is successful:

12/06/2012 17:09:53.377 (2104): ++++++ Request sent to device ++++++ 12/06/2012 17:09:53.377 (2104): Change of Authorization Request Packet 12/06/2012 17:09:53.377 (2104): (String ) Acct-Session-Id = '48' (2 bytes) 12/06/2012 17:09:53.377 (2104): (String ) Unisphere-Egress-Policy-Name = 'police-10M' (10 bytes) 12/06/2012 17:09:53.377 (2104): ------ End Request sent to device ------ 12/06/2012 17:09:53.377 (2104): 12/06/2012 17:09:53.377 (2104): 12/06/2012 17:09:53.377 (2104): started RADIUS request against target 'MX:RFC3576' 12/06/2012 17:09:53.377 (2084): formatting proxy request for target number 0 12/06/2012 17:09:53.377 (2084): proxy work has next scheduled send at time 1354831796 12/06/2012 17:09:53.377 (2084): calculated delay is 3000 12/06/2012 17:09:53.377 (2084): proxy target sequence processing: 12/06/2012 17:09:53.377 (2084): considering reference 0 = target 0 12/06/2012 17:09:53.377 (2084): considering sending to target 0 12/06/2012 17:09:53.377 (2084): not yet fast fail, wait for response from this target 12/06/2012 17:09:53.377 (2084): 12/06/2012 17:09:53.385 (3107): received proxy response at time 1354831793


12/06/2012 17:09:53.385 (2084): 12/06/2012 17:09:53.385 (2084): ++++++ Response received from device ++++++ 12/06/2012 17:09:53.385 (2084): Transaction Result = session control request successful 12/06/2012 17:09:53.385 (2084): 12/06/2012 17:09:53.385 (2084): ------ End Response received from device ------

Finally, after a successful CoA against the MX, the MX sends a new Acct Interim message with the new Egress-Policy-Name. Acct Interim is Acct-Status-Type = 3, as bolded below:

12/06/2012 17:12:16.682 (3102): ----------------------------------------------------------- 12/06/2012 17:12:16.682 (3102): Accounting Request 12/06/2012 17:12:16.682 (3102): Received from IpAddr=10.10.10.101 Port=62354 12/06/2012 17:12:16.682 (3102): Packet Code=0x04 Id=0xef 12/06/2012 17:12:16.682 (3102): Client Name="MX" 12/06/2012 17:12:16.682 (3102): Dictionary Name="unisphereMX11-2.dct" 12/06/2012 17:12:16.682 (3102): Vector = 12/06/2012 17:12:16.682 (3102): 000: 4e d0 4c fb 50 0d c3 7d c2 27 c7 47 e0 64 4e 5b |N.L.P..}.'.G.dN[| 12/06/2012 17:12:16.682 (3102): Parsed Packet : 12/06/2012 17:12:16.682 (3102): User-Name : String Value = foobar.0050.56bd.0035 12/06/2012 17:12:16.682 (3102): Acct-Status-Type : Integer Value = 3 12/06/2012 17:12:16.682 (3102): Acct-Session-Id : String Value = 48 12/06/2012 17:12:16.682 (3102): Acct-Session-Time : Integer Value = 70806 12/06/2012 17:12:16.682 (3102): Service-Type : Integer Value = 2 12/06/2012 17:12:16.682 (3102): Acct-Authentic : Integer Value = 1 12/06/2012 17:12:16.682 (3102): Acct-Delay-Time : Integer Value = 0 12/06/2012 17:12:16.682 (3102): Class : Value = 12/06/2012 17:12:16.682 (3102): 000: 53 42 52 32 43 4c fd af fa 88 a7 ea ff d0 c2 80 |SBR2CL..........| 12/06/2012 17:12:16.682 (3102): 010: 11 80 34 01 80 02 81 98 80 02 80 18 81 a3 93 e9 |..4.............| 12/06/2012 17:12:16.682 (3102): 020: f4 92 85 a4 ae 98 8c 86 d3 81 b8 ea b6 a1 91 85 |................| 12/06/2012 17:12:16.682 (3102): 030: e3 81 c0 e6 b5 12 80 0e 81 fd af fa 88 a1 c4 87 |................| 12/06/2012 17:12:16.682 (3102): 040: c0 a8 80 80 80 80 9c |....... | 12/06/2012 17:12:16.682 (3102): Unisphere-Dhcp-Options : Value = 12/06/2012 17:12:16.682 (3102): 000: 35 01 01 3d 07 01 00 50 56 bd 00 35 0c 07 53 52 |5..=...PV..5..SR| 12/06/2012 17:12:16.682 (3102): 010: 43 2d 50 43 32 3c 08 4d 53 46 54 20 35 2e 30 37 |C-PC2<.MSFT 5.07| 12/06/2012 17:12:16.682 (3102): 020: 0c 01 0f 03 06 2c 2e 2f 1f 21 79 f9 2b |.....,./.!y.+ | 12/06/2012 17:12:16.682 (3102): Unisphere-Dhcp-Mac-Addr : String Value = 0050.56bd.0035 12/06/2012 17:12:16.682 (3102): Unisphere-Egress-Policy-Name : String Value = police-10M 12/06/2012 17:12:16.682 (3102): Event-Timestamp : Integer Value = 1354815559 12/06/2012 17:12:16.682 (3102): Framed-IP-Address : IPAddress = 10.10.10.51 12/06/2012 17:12:16.682 (3102): Framed-IP-Netmask : IPAddress = 255.255.255.0


12/06/2012 17:12:16.682 (3102): Unisphere-Ingress-Policy-Name : String Value = police-2M 12/06/2012 17:12:16.682 (3102): NAS-Identifier : String Value = Camlab 12/06/2012 17:12:16.682 (3102): NAS-Port : Integer Value = 536875007 12/06/2012 17:12:16.682 (3102): NAS-Port-ID : String Value = ge-2/2/0.0 12/06/2012 17:12:16.682 (3102): NAS-Port-Type : Integer Value = 15 12/06/2012 17:12:16.682 (3102): NAS-IP-Address : IPAddress = 10.10.10.101 12/06/2012 17:12:16.682 (3102): -----------------------------------------------------------

Summary

Congratulations, you made it to the end of the book! Hopefully you grasp the fundamentals of how CoA can be used to affect the charac-teristics of a dynamic profile used in subscriber management on the MX, in addition to how SBR can be used along with web services to invoke those CoA requests.

You should also have learned some new debugging techniques using log files on both SBR and the MX, as well as some techniques on how to configure the SBR for various CoA actions, as a part of reading this book..

Our intent was to get a simple self-service web portal active, which allows a subscriber to change the characteristics of their session. There are many other use cases that can be developed using the fundamentals presented. For instance, that self-service portal could easily become a provisioning system, a captive portal, or even become an external system like a video-on-demand server that could issue CoA’s to make the subscriber session conform to the requirements of the server.

I couldn’t cover it all, so please, use this book as a “I didn’t know I could do that.” And then get in the lab. As always, there is a lot more technical documentation available on www.juniper.net/techpubs for you to read through, as well as the companion Day One book to this one – Day One: Dynamic Subscriber Management.

I hope this book was helpful and that you have fun with this it. – John Rolfe

http://www.juniper.net/techpubs

Documents

Day One: SBR Change of Authorization (CoA) and the MX Series · In this book you’ll see how Juniper’s subscriber management solution (the MX Series and Steel Belted RADIUS) can