DO SBR CoA

Junos Networking Technologies
Day One:
SBR Change of Authorization
(CoA) and the MX Series
Build a MX subscriber management

solution along with RADIUS authentication, authorization, accounting,
and Change of Authorization (CoA)
using Junipers Steel-Belted Radius.
By John Rolfe
DAY ONE: SBR Change of Authorization (CoA)

and the MX Series
This book describes the steps needed to build a MX subscriber management solution along with RADIUS authentication, authorization, accounting, and change of authorization using Junipers 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 youll be
able to explore these and other use cases for your own network needs.
ITS 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.
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
ISBN 978-1936779635
51200
07100164
9 781936 779635
Junos Networking Technologies
Day One: SBR Change of Authorization (CoA)

and the MX Series
By John Rolfe
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
iv
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 Books
Author: John Rolfe
Technical Reviewers: Hartmut Schroeder, Wayne
Brassem, Jon Canchola, and Devasena Morrissette
Editor in Chief: Patrick Ames
Copyeditor and Proofer: Nancy Koerbel
J-Net Community Manager: Julie Wider
About the Author

John 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.
Authors Acknowledgments
Thank 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 dayone@juniper.net.
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.
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, Youll 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.
About Change of Authorization

This book describes the steps needed to deploy an MX subscriber
management solution along with RADIUS authentication, authorization, accounting, and Change of Authorization using Junipers 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 lets 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 Management at http://www.juniper.net/dayone. This is also a good resource for
Class of Services issues in Dynamic Subscriber Management.
vii
viii
Chapter 1
MX Dynamic Subscriber Management
The Lab Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
The Basic Use Case and Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Change of Authorization (CoA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10
Day One: SBR Change of Authorization (CoA) and the MX Series
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 youll see how Junipers 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. Theres a logical progression 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 understanding of what can be done to the subscribers connection parameters 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 networks, 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
Chapter 1: MX Dynamic Subscriber Management
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 Providers network, the subscribers will typically come in

off of DSLAMs, ONTs, 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 VLANs 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, its 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.
11
12
Figure 1.2
Ladder Diagram of a New Subscriber Connection
When a subscriber connection comes active, it issues a DHCP discovery, 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 MACAddress 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,
its not technically authenticating anything, its 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
Chapter 1: MX Dynamic Subscriber Management
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 subscribers 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-IPAddress (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 AccountingSession-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. Its 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.
13
14
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
MLD-Access-Source-Group-Name
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
16
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, lets
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 MXs (the 240, 480, and 960), the SKU is
S-SA-FP; for the MX80 family the SKU is S-MX80-SA-FP. These
SKUs are Feature Pack for Subscriber Access features.
Chapter 2: Setting Up the MX
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 permanent
Licenses 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
permanent
License 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
17
18
Configuring the Loopback Interface

In this books 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 its
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 Subscriber 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.
In Junos, you configure multiple pools in the [access address-assignment] hierarchy, and control in the [system services dhcp-local-server]
hierarchy.
For this books 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-address-first to select the DHCP pool to use. Authentication is set up to
19
20
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 its 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-localserver] 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;
}
}
}
}
}
}
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. Heres 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.
Lets check the connection on the MX with a show command:
[edit]
root@Camlab# run show subscribers
Interface IP Address/VLAN ID User NameLS:RI
demux0.1073741886 10.10.10.57 foobar.0050.56bd.0035default:default
21
22
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 its 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 hierarchy 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;
}
then discard;
}
policer 10M {
if-exceeding {
bandwidth-limit 10m;
}
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. Its
23
24
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 dynamicprofile, 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 {
demux-options {
}
family inet {
demux-source {
}
filter {
input police-2M;
output police-2M;
}
}
}
}
}
}
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 IDUser Name LS:RI
demux0.1073741888
10.10.10.58foobar.0050.56bd.0035default: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 13642
Filter: 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-incontains 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 authorization 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 lets get
ready for SBR.
25
26
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
28
This chapter describes the setup of SBR Carrier to control the authorization 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-CARSCM)
SCM stands for Session Control Module and allows for CoA/DM, as
well as for Cisco IOSs 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 VirtualMachine (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 described 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 localinstall <sbr rpm file name>.
Chapter 3: Adding SBR to the Configuration
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 wont 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 aforementioned 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 its a <new> installation, 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:
29
30
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]# ./sbrd
SYNOPSIS: 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-address>: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.
31
32
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 youre 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 theres 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 thats 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 management. 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 management.
NOTE
Its 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
dictionary
ignore-ports
port-number-usage
help-id
=
=
=
=
=
Unisphere MX with JUNOS v11.2

unisphereMX11-2
no
per-port-type
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
33
34
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. Lets
start with clients.
Radius Client (the MX)

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 wont 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 youre done click OK, and the client is added. Theres 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 wont 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-
35
36
ing the MX expects RADIUS to return values for these firewall filter
names:
IPDemux {
interfaces {
demux0 {
demux-options {
}
family inet {
demux-source {
}
filter {
input police-2M;
output police-2M;
}
}
}
}
}
}
Setting Up the Profile Return List

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-PolicyName 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.
Native Users
A user database that is internal to the SBR server is called native users.
Its 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 authorization. In this book, lets just use the internal database for simplicity.
The native users 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 users panel in the left-hand pane and open
native users.
37
38
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 thats all thats 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 lets 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. Its called authentication
server in the MX, but again, technically its 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

root@Camlab# set authentication password juniper
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;
}
}
group local {
}
root@Camlab#
39
40
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. Its 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. Its 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 extensive 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:
root@Camlab# show
IPDemux {
interfaces {
demux0 {
demux-options {
}
family inet {
demux-source {
}
filter {
input "$junos-input-filter";
output "$junos-output-filter";
}
}
}
}
}
}
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 didnt 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.
41
42
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 its been tested in Chapter 2, we wont use it here, but if
its 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;
}
}
group local {
}
}
[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.
Monitor general-authentication-server Log

Now lets 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
43
44
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
MX DHCP Address Allocation

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 framedip-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 its not
available in time for the accounting start. Lets 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 ~DynamicRequestEntry
Nov 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: police2M
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
45
46
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
Steel Belted Radius logs

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
--11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
--11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
|J..........i.u6s|
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
|...W..%h;l..[...|
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
11/13/2012 20:14:18.469
(2212): ----------------------------------------------------(2212):
(2212):
(2212):
(2303):
(2303):
(2303):
(2303):
(2303):
(2303):
(2303):
(2303):
(2303):
(2303):
Authentication Request
Received from IpAddr=10.10.10.101 Port=62354
(2303):
(2303):
(2303):
(2303):
(2303):
(2303):
(2303):
Authentication Request
Packet Code=0x01 Id=0x7f
Client Name="MX"
Dictionary Name="unisphereMX11-2.dct"
Vector =
000: 4a 96 c0 0a df 0d b2 9d 82 02 90 69 8e 75 36 73
(2303):
(2303):
(2303):
(2303):
Parsed Packet :
User-Name : String Value = foobar.0050.56bd.0035
User-Password : Value =
000: 96 a4 fe 57 ff b0 25 68 3b 6c ed c5 5b fe 9d e3
(2303):
(2303):
(2303):
(2303):
(2303):
Service-Type : Integer Value = 2

Chargeable-User-Identity : String Value =
Acct-Session-Id : String Value = 21
Unisphere-Dhcp-Options : Value =
000: 35 01 01 3d 07 01 00 50 56 bd 00 35 0c 07 53 52
Entering
Looking up shared secret
Looking for RAS client 10.10.10.101 in DB
Matched 10.10.10.101 to RAS client MX
Parsing request
Initializing cache entry
Doing inventory check on request
Getting info on requesting client
NAS-IP-Address in request: 10.10.10.101
-----------------------------------------------------
|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 NativeUser 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
47
48
|....... |
11/13/2012 20:14:18.471 (2303): Unisphere-Egress-Policy-Name : String Value = police2M
11/13/2012 20:14:18.471 (2303): Unisphere-Ingress-Policy-Name : String Value = police2M
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 = police2M
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 = police2M
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
49
50
|.... |
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 MXs dynamic profile using
VSAs in SBR and $junos variables in the MX, and has further attempted 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
52
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 attributes that correspond to firewall filters that are applied to the subscribers 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 SBRs Current Session Table (CST).
(The access request and access accept build whats 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 accounting start, such as Framed-IP-Address, NAS-IP-Address, and Accounting-Session-ID. The accounting-session-ID is a number generated by
the MX to uniquely identify this session, and is stored in SBRs 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 installation time. In the cluster version of SBR, called the Session State Registrar (SSR), the CST schema is configurable and uses a version of
MySQL cluster to build the CST. Regardless of whether its 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
Chapter 4: Basic CoA Setup Using SBR GUI
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 dont 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.
53
54
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 unisphereegress-policy-name. For this book, CoA simply changes the unisphereegress-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>
<overrideAttribute name="Unisphere-egress-policy-name"
value="police-10M"/>
</attributes>
</RADIUSRequest>
</action>
<attributes>
value="police-5M"/>
</attributes>
</RADIUSRequest>
</action>
<attributes>
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 SBRs 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
55
56
should only require two attributes: the Acct-Session-ID and the

Unisphere-egress-policy-name. The attributes are tagged with requiredAttribute 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 books 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:
<attributes>
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 Ciscos 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 dont 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 Administrators 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 configured 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:
57
58
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, lets view the session and associated firewall
filters on the MX:
root@Camlab> show subscribers
Interface IP Address/VLAN IDUser NameLS:RI
demux0.1073741828 10.10.10.53foobar.0050.56bd.0035 default:default
root@Camlab> show firewall
Policers:
Name Bytes Packets
2M-all-demux0.1073741828-in 0 0
Policers:
Name Bytes Packets
2M-all-demux0.1073741828-out 0 0
root@Camlab>
The show command shows the session is active along with the RADIUS-initiated firewall filters police-2M.
Now lets initiate a Boost10M CoA. In the SBR GUI simply highlight
the session and click on Boost10M, and the following window should
appear.
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
Policers:
Name Bytes Packets
2M-all-demux0.1073741828-in 0 0
59
60
Policers:
Name Bytes Packets
10M-all-demux0.1073741828-out 0 0
root@Camlab>
Testing the Configuration Debug Logs

To debug the configuration, lets start with the logs on SBR. Log files
are located in /opt/JNPRsbr/RADIUS and are named YYYYMMDD.log.
Tracking todays 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 = '0a0a
0a35000000000000000000000000' (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
11/06/2012
11/06/2012
11/06/2012
11/06/2012
11/06/2012
bytes)
11/06/2012
11/06/2012
11/06/2012
bytes)
11/06/2012
11/06/2012
11/06/2012
11/06/2012
11/06/2012
11/06/2012
11/06/2012
20:00:21.110
20:00:21.110
20:00:21.111
20:00:21.111
20:00:21.111
20:00:21.111
(2140):
(2140):
(2140):
(2140): ++++++ Request for individual session ++++++
(2140): Request
(2140): (String ) User-Name = 'FOOBAR.0050.56BD.0035' (21
20:00:21.111 (2140): (Integer32 ) NAS-Port = '536875007' (4 bytes)

20:00:21.111 (2140): (Integer32 ) NAS-Port-Type = '15' (4 bytes)
20:00:21.111 (2140): (IP Address) Framed-IP-Address = '10.10.10.53' (4
20:00:21.111
20:00:21.111
20:00:21.111
20:00:21.111
20:00:21.111
20:00:21.111
20:00:21.111
(2140):
(2140):
(2140):
(2140):
(2140):
(2140):
(2140):
(String ) Acct-Session-Id = '16' (2 bytes)

(IP Address) NAS-IP-Address = '10.10.10.101' (4 bytes)
(String ) NAS-Identifier = 'MX' (2 bytes)
------ End Request for individual session ------
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
11/06/2012 20:00:21.111
11/06/2012 20:00:21.111
11/06/2012 20:00:21.111
10M' (10 bytes)
11/06/2012 20:00:21.111
11/06/2012 20:00:21.111
11/06/2012 20:00:21.111
11/06/2012 20:00:21.111
'MX:RFC3576'
11/06/2012 20:00:21.111
11/06/2012 20:00:21.111
1352250024
11/06/2012 20:00:21.111
11/06/2012 20:00:21.111
11/06/2012 20:00:21.111
11/06/2012 20:00:21.111
11/06/2012 20:00:21.111
target
11/06/2012 20:00:21.111
11/06/2012 20:00:21.261
11/06/2012 20:00:21.261
(2140):
(2140):
(2140):
(2140):
++++++ Request sent to device ++++++

Change of Authorization Request Packet
(String ) Unisphere-Egress-Policy-Name = 'police-
(2140): ------ End Request sent to device -----(2140):

(2140):
(2140): started RADIUS request against target
(2121): formatting proxy request for target number 0
(2121): proxy work has next scheduled send at time
(2121):
(2121):
(2121):
(2121):
(2121):
calculated delay is 3000

proxy target sequence processing:
considering reference 0 = target 0
considering sending to target 0
not yet fast fail, wait for response from this
(2121):
(10122): received proxy response at time 1352250021
(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 ++++++
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:
61
62
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-SessionId" copyFrom="Acct-Session-Id"/>
11/06/2012 20:00:21.261 (2121): Override: <overrideAttribute name="Unisphereegress-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 ++++++
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>;
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_callback
Nov 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.
63
64
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, lets put it all to use with self-service
portal that can now be developed using the SBRs 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
66
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
MP-Access-Source-Group-Name
MLD-Access-Group-Name
MLD-Access-Source-Group-Name
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, its 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 subscriber 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 deviceModels.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:
Chapter 5: Simple Web Portal
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 recommended 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:
67
68
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 theres issues starting or communicating 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.apachefriends.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
69
70
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.
$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
print
print
print
?>
"<strong>Hello:</strong><br />\n";
"$ip<br /><br />\n";
"<strong>Also Known as:</strong><br />\n";
"$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:
<attributes>
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 its 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: its important to
note that there isnt any error handling or corner cases in this script. Its
just a simple PHP script:
radioButton.php
<?PHP
//read input from order.php and print
$selected_radio=$_POST['group1'];
print $selected_radio;
71
72
//header ('Content-type: text/xml');

//set $ip variable to ip address of client
//set XML envelopes to be sent to SBR
$Boost10M="<envelope>
<header />
<body>
<attributes>
<attribute enabled='true' name='Framed-IP-Address' value='$ip'/>
</attributes>
</request>
</body>
</envelope>";
<header />
<body>
<attributes>
<attribute name='Framed-IP-Address' value='$ip'/>
</attributes>
</request>
</body>
</envelope>";
<header />
<body>
<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 handle

curl_close($ch);
}
// executes the appropriate XML based on radiobutton
if ($selected_radio=="Gold")
{

$fromssr = getfromssr($Boost10M);
}
elseif ($selected_radio=="Silver")
{

}
elseif ($selected_radio=="Bronze")
{

}
{

}
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. Thats all thats 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. Lets go to http://<Apache_IP_Address>/xampp/order.php.
73
74
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 defining another administrator in the SBR admin GUI with superuser
privileges, and then using that users credentials in the getfromssr
routine:
12/06/2012 17:09:53.356
12/06/2012 17:09:53.356
12/06/2012 17:09:53.356
12/06/2012 17:09:53.356
reques|
12/06/2012 17:09:53.356
HTTP/1.1..Aut|
12/06/2012 17:09:53.356
Basi|
12/06/2012 17:09:53.356
cm9vdDpDYW1sYW|
12/06/2012 17:09:53.356
(2196):
(2196):
(2196):
(2196):
MCI notification in admin session; incoming session

MDI notification in admin session; data is available
admin interface incoming raw request (378 bytes):
000: 504f5354 202f7363 732f7265 71756573 |POST /scs/
(2196): 010: 742f2048 5454502f 312e310d 0a417574 |t/

(2196): 020: 686f7269 7a617469 6f6e3a20 42617369 |horization:
(2196): 030: 6320636d 39766444 70445957 31735957 |c
(2196): 040: 49784d6a 4d3d0d0a 486f7374 3a203130 |IxMjM=..
75
76
Host: 10|
12/06/2012 17:09:53.356
|.10.10.102:1813.|
12/06/2012 17:09:53.356
*/*..Co|
12/06/2012 17:09:53.356
Length: 19|
12/06/2012 17:09:53.356
Type:|
12/06/2012 17:09:53.356
application/x-w|
12/06/2012 17:09:53.356
urlencod|
12/06/2012 17:09:53.356
|ed....<envelope>|
12/06/2012 17:09:53.356
/>..<b|
12/06/2012 17:09:53.356
|ody>..<request a|
12/06/2012 17:09:53.356
|ction='Boost10M'|
12/06/2012 17:09:53.356
|>..<attributes>.|
12/06/2012 17:09:53.356
enab|
12/06/2012 17:09:53.356
name=|
12/06/2012 17:09:53.356
Addre|
12/06/2012 17:09:53.356
value='10.10|
12/06/2012 17:09:53.356
|.10.51'/>..</att|
12/06/2012 17:09:53.356
requ|
12/06/2012 17:09:53.356
body>..<|
12/06/2012 17:09:53.356
|
12/06/2012 17:09:53.356
12/06/2012 17:09:53.356
12/06/2012 17:09:53.376
12/06/2012 17:09:53.376
12/06/2012 17:09:53.376
12/06/2012 17:09:53.376
12/06/2012 17:09:53.376
12/06/2012 17:09:53.376
12/06/2012 17:09:53.376
12/06/2012 17:09:53.376
12/06/2012 17:09:53.376
12/06/2012 17:09:53.376
12/06/2012 17:09:53.376
user 'root'
12/06/2012 17:09:53.376
(2196): 050: 2e31302e 31302e31 30323a31 3831330d

(2196): 060: 0a416363 6570743a 202a2f2a 0d0a436f |.Accept:
(2196): 070: 6e74656e 742d4c65 6e677468 3a203139 |ntent(2196): 080: 360d0a43 6f6e7465 6e742d54 7970653a |6..Content(2196): 090: 20617070 6c696361 74696f6e 2f782d77 |
(2196): 0a0: 77772d66 6f726d2d 75726c65 6e636f64 |ww-form(2196): 0b0: 65640d0a 0d0a3c65 6e76656c 6f70653e
(2196): 0c0: 0d0a3c68 65616465 72202f3e 0d0a3c62 |..<header
(2196): 0d0: 6f64793e 0d0a3c72 65717565 73742061
(2196): 0e0: 6374696f 6e3d2742 6f6f7374 31304d27
(2196): 0f0: 3e0d0a3c 61747472 69627574 65733e0d
(2196): 100: 0a3c6174 74726962 75746520 656e6162 |.<attribute
(2196): 110: 6c65643d 27747275 6527206e 616d653d |led='true'
(2196): 120: 27467261 6d65642d 49502d41 64647265 |'Framed-IP(2196): 130: 73732720 76616c75 653d2731 302e3130 |ss'
(2196): 140: 2e31302e 3531272f 3e0d0a3c 2f617474
(2196): 150: 72696275 7465733e 0d0a3c2f 72657175 |ributes>..</
(2196): 160: 6573743e 0d0a3c2f 626f6479 3e0d0a3c |est>..</
(2196): 170: 2f656e76 656c6f70 653e |/envelope>
(2196):
(2196):
(2196):
(2196):
(2196):
(2196):
(2196):
(2196):
(2196):
(2196):
(2196):
(2196):
(2196):
admin interface recognized request

admin session authenticated; user is 'root'
admin session authenticated; user is in group 'root'
admin session authenticated; user is in group 'root'
admin session authenticated; user is in group 'bin'
admin session authenticated; user is in group 'daemon'
admin session authenticated; user is in group 'sys'
admin session authenticated; user is in group 'adm'
admin session authenticated; user is in group 'disk'
admin session authenticated; user is in group 'wheel'
user 'root' connected to admin interface
admin session assigning access level 'SuperAdmin' to
(2196): found POST target resource at URI '/scs/request/'
12/06/2012
12/06/2012
12/06/2012
12/06/2012
12/06/2012
bytes)
12/06/2012
17:09:53.376
17:09:53.377
17:09:53.377
17:09:53.377
17:09:53.377
(2196):
(2104):
(2104):
(2104):
(2104):
pausing stream
++++++ Request received from user ++++++
Request
(IP Address) Framed-IP-Address = '10.10.10.51' (4
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
12/06/2012
12/06/2012
bytes)
12/06/2012
12/06/2012
12/06/2012
bytes)
12/06/2012
12/06/2012
12/06/2012
12/06/2012
17:09:53.377 (2104): ++++++ Request for individual session ++++++

17:09:53.377 (2104): Request
17:09:53.377 (2104): (String ) User-Name = 'FOOBAR.0050.56BD.0035' (21
17:09:53.377 (2104): (Integer32 ) NAS-Port = '536875007' (4 bytes)
17:09:53.377 (2104): (Integer32 ) NAS-Port-Type = '15' (4 bytes)
17:09:53.377 (2104): (IP Address) Framed-IP-Address = '10.10.10.51' (4
17:09:53.377
17:09:53.377
17:09:53.377
17:09:53.377
(2104):
(2104):
(2104):
(2104):

(IP Address) NAS-IP-Address = '10.10.10.101' (4 bytes)
(String ) NAS-Identifier = 'MX' (2 bytes)
------ End Request for individual session ------
Once SBR has looked up the session and can resolve the Acct-SessionId, it processes the CoA message using the packing list in deviceModels.xml. And youll 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 = 'police10M' (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
77
78
12/06/2012
12/06/2012
12/06/2012
successful
12/06/2012
12/06/2012
17:09:53.385 (2084):
17:09:53.385 (2084): ++++++ Response received from device ++++++
17:09:53.385 (2084): Transaction Result = session control request
17:09:53.385 (2084):
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
-----12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
|N.L.P..}.'.G.dN[|
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
|SBR2CL..........|
12/06/2012 17:12:16.682
|..4.............|
12/06/2012 17:12:16.682
|................|
12/06/2012 17:12:16.682
|................|
12/06/2012 17:12:16.682
|....... |
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
|5..=...PV..5..SR|
12/06/2012 17:12:16.682
|C-PC2<.MSFT 5.07|
12/06/2012 17:12:16.682
|.....,./.!y.+ |
12/06/2012 17:12:16.682
0050.56bd.0035
12/06/2012 17:12:16.682
10M
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
12/06/2012 17:12:16.682
(3102): ----------------------------------------------------(3102):
(3102):
(3102):
(3102):
(3102):
(3102):
(3102):
Accounting Request
Packet Code=0x04 Id=0xef
Client Name="MX"
Dictionary Name="unisphereMX11-2.dct"
Vector =
000: 4e d0 4c fb 50 0d c3 7d c2 27 c7 47 e0 64 4e 5b
(3102):
(3102):
(3102):
(3102):
(3102):
(3102):
(3102):
(3102):
(3102):
(3102):
Parsed Packet :
User-Name : String Value = foobar.0050.56bd.0035
Acct-Status-Type : Integer Value = 3
Acct-Session-Id : String Value = 48
Acct-Session-Time : Integer Value = 70806
Service-Type : Integer Value = 2
Acct-Authentic : Integer Value = 1
Acct-Delay-Time : Integer Value = 0
Class : Value =
000: 53 42 52 32 43 4c fd af fa 88 a7 ea ff d0 c2 80
(3102): 010: 11 80 34 01 80 02 81 98 80 02 80 18 81 a3 93 e9
(3102): 020: f4 92 85 a4 ae 98 8c 86 d3 81 b8 ea b6 a1 91 85
(3102): 030: e3 81 c0 e6 b5 12 80 0e 81 fd af fa 88 a1 c4 87
(3102): 040: c0 a8 80 80 80 80 9c
(3102): Unisphere-Dhcp-Options : Value =
(3102): 000: 35 01 01 3d 07 01 00 50 56 bd 00 35 0c 07 53 52
(3102): 010: 43 2d 50 43 32 3c 08 4d 53 46 54 20 35 2e 30 37
(3102): 020: 0c 01 0f 03 06 2c 2e 2f 1f 21 79 f9 2b
(3102): Unisphere-Dhcp-Mac-Addr : String Value =
(3102): Unisphere-Egress-Policy-Name : String Value = police(3102): Event-Timestamp : Integer Value = 1354815559
(3102): Framed-IP-Address : IPAddress = 10.10.10.51
(3102): Framed-IP-Netmask : IPAddress = 255.255.255.0
12/06/2012
2M
12/06/2012
12/06/2012
12/06/2012
12/06/2012
12/06/2012
12/06/2012
------
17:12:16.682 (3102): Unisphere-Ingress-Policy-Name : String Value = police17:12:16.682

17:12:16.682
17:12:16.682
17:12:16.682
17:12:16.682
17:12:16.682
(3102):
(3102):
(3102):
(3102):
(3102):
(3102):
NAS-Identifier : String Value = Camlab

NAS-Port : Integer Value = 536875007
NAS-Port-ID : String Value = ge-2/2/0.0
NAS-Port-Type : Integer Value = 15
NAS-IP-Address : IPAddress = 10.10.10.101
-----------------------------------------------------
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 characteristics 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 CoAs to make
the subscriber session conform to the requirements of the server.
I couldnt cover it all, so please, use this book as a I didnt 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
79
80

DO SBR CoA

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

DO SBR CoA

Hochgeladen von

Copyright:

Verfügbare Formate

Junos Networking Technologies

Build a MX subscriber management

DAY ONE: SBR Change of Authorization (CoA)

Junos Networking Technologies

Day One: SBR Change of Authorization (CoA)

2013 by Juniper Networks, Inc. All rights reserved.

About the Author

Welcome to Day One

What You Need to Know Before Reading This Book

After Reading This Book, Youll Be Able To:

About Change of Authorization

Day One: SBR Change of Authorization (CoA) and the MX Series

This chapter introduces you to RADIUS-based dynamic subscriber

The Lab Setup

The SBR server can be installed in a Centos Linux VM on the same PC

Chapter 1: MX Dynamic Subscriber Management

The Lab for this Book

In a Service Providers network, the subscribers will typically come in

The Basic Use Case and Flow

Day One: SBR Change of Authorization (CoA) and the MX Series

Ladder Diagram of a New Subscriber Connection

Chapter 1: MX Dynamic Subscriber Management

Change of Authorization (CoA)

Day One: SBR Change of Authorization (CoA) and the MX Series

Input policy name to apply to client interface.

Output policy name to apply to client interface

Enable or disable IGMP on a client interface

Traffic mirroring action

Handle Link to which traffic mirroring is applied

Enable or disable statistics for the service

Access list to use for the group filter

Access list to use for the source-group filter

Access list to use for the group filter

Access list to use for the source-group filter

MLD protocol version

IGMP protocol version

IGMP immediate leave

MLD immediate leave

Input policy to apply to a user IPv6 interface

Output policy to apply to a user IPv6 interface

CoS traffic shaping parameter type

Interface set to apply to the dynamic profile

Amount of time between accounting interims for this service

CoS scheduler parameter types

Day One: SBR Change of Authorization (CoA) and the MX Series

MX Configuration for DHCP Local Server

The steps needed to configure this basic setup are:

Chapter 2: Setting Up the MX

The second license is for session scale. These are available in

Day One: SBR Change of Authorization (CoA) and the MX Series

Configuring the Loopback Interface

The configuration is using a demux-source inet (IPV4) and using the

Configuring the DHCP Local Server

Chapter 2: Setting Up the MX

The example shows a pool name, DHCP, using the 10.10.10.0/24

Day One: SBR Change of Authorization (CoA) and the MX Series

Configuring the Dynamic Profile

Chapter 2: Setting Up the MX

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

Checkpoint Validating the Configuration

Day One: SBR Change of Authorization (CoA) and the MX Series

The MX has assigned the interface name demux0.1073741886 to this

Using the interface name demux0.1073741886 in the show subscribers