SBR change of authorization (coa) and the MX series

SBR change of authorization (coa) and the MX series

Build a MX subscriber management

solution along with RADiuS

authen-tication, authorization, accounting,

and Change of Authorization (CoA)

using Juniper’s Steel-Belted Radius.

By John Rolfe

SBR CHANge OF AUTHORIzATION (CoA) AND THe MX SeRIeS

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

Published by Juniper Networks Books

AND thE MX SERiES

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

solu-Day One: SBR Change of Authorization (CoA) and the MX Series is meant for the lab, for

a day exploring the basic tenets of software defined networks (SDN) by using the MX Series, Junos, and SBR to create a CoA solution

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

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

n Handle DHCP subscribers using MX DHCP local server

n Configure IP demux on the subscriber interface

n Create QoS configuration templates for deployment

n Build dynamic profiles using the firewall filter/policer for QOS

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

n Utilize SBR Carrier XML over HTTPS API

n Perform PHP scripting to implement the HTTPS XML post

n Build a basic Apache web server page

ISBN 978-1936779635

9 781936 779635

5 1 2 0 0

07100164

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

By John Rolfe

Chapter 1 : MX Dynamic Subscriber Management 9

Chapter 2 : Setting Up the MX 15

Chapter 3 : Adding SBR to the Configuration 27

Chapter 4: Basic CoA Setup Using SBR GUI .51

Chapter 5: Simple Web Portal 65

© 2013 by Juniper Networks, Inc All rights reserved

Juniper Networks, the Juniper Networks logo, Junos,

NetScreen, and ScreenOS are registered trademarks of

Juniper Networks, Inc in the United States and other

countries Junose is a trademark of Juniper Networks,

Inc All other trademarks, service marks, registered

trademarks, or registered service marks are the property

of their respective owners

Juniper Networks assumes no responsibility for any

inaccuracies in this document Juniper Networks reserves

the right to change, modify, transfer, or otherwise revise

this publication without notice Products made or sold by

Juniper Networks or components thereof might be

covered by one or more of the following patents that are

owned by or licensed to Juniper Networks: U.S Patent

Nos 5,473,599, 5,905,725, 5,909,440, 6,192,051,

6,333,650, 6,359,479, 6,406,312, 6,429,706,

6,459,579, 6,493,347, 6,538,518, 6,538,899,

6,552,918, 6,567,902, 6,578,186, and 6,590,785

Published by Juniper Networks 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

Author’s 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-enThis 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.

What You Need to Know Before Reading This Book

Before reading this book, you should be familiar with the basic administrative functions of the Junos operating system, including the ability to work with operational commands and to read, understand,

and change Junos configurations There are several books in the Day

One library on exploring and learning Junos, at www.juniper.net/

dayone.

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

„ You are versed in authentication principles

„ You have operational experience with the MX Series.

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

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

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

„ Handle DHCP subscribers using MX DHCP local server.

„ Configure IP demux on the subscriber interface.

„ Create QoS configuration templates for deployment.

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

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

„ Utilize SBR Carrier XML over HTTPS API.

„ Perform PHP scripting to implement the HTTPS XML post.

„ Build a basic Apache web server page.

About Change of Authorization

This book describes the steps needed to deploy an MX subscriber management solution along with RADIUS authentication, authoriza- tion, accounting, and Change of Authorization using Juniper’s Steel Belted Radius (SBR) The book walks you through a basic dynamic profile on the MX step-by-step, setting firewall/policers to the profile via RADIUS, and then changing those values via RADIUS CoA The final chapter guides you through the required XML envelopes, setting

up a web server, and implementing a self-service portal to invoke the CoA It utilizes an HTML Web page with a PHP script built on XAMPP (from Apache Friends), which includes the Apache web server along with PHP, Perl, and other components

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

„ Automating service provisioning

„ Self service portal for network and subscriber provisioning

„ Captive portal services for delinquent accounts/terms and conditions

„ Service provider Wi-Fi captive portal

„ Credit card authenticating portals

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

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

MORE? For VLAN models please see Day One: Dynamic Subscriber

Manage-ment at http://www.juniper.net/dayone This is also a good resource for

Class of Services issues in Dynamic Subscriber Management.

Chapter 1

MX Dynamic Subscriber Management

The Lab Setup 10

The Basic Use Case and Flow 11

Change of Authorization (CoA) 13

This chapter introduces you to RADIUS-based dynamic subscriber management on the MX series, along with the concepts of Junos variables ($junos) in the MX and how those concepts relate to RADIUS attributes This chapter may seem like a recap of another Day

One book - Day One: Dynamic Subscriber Management – but it

includes an introduction to the concept of in-session changes (Change

of Authorization, or CoA) and some of the use cases associated with it

In this book you’ll see how Juniper’s subscriber management solution (the MX Series and Steel Belted RADIUS) can be controlled by external web pages or systems invoking dynamic changes on the subscriber session While this book focuses on dynamic changes on the firewall filter, any RADIUS controlled attribute could be used, depending on your use case Which is kind of cool.

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

The Lab Setup

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

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

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

running Apache – place it in bridged mode so it has its own IP address

NOTE SBR needs to run on Red Hat Enterprise Server in production

net-works, but Centos is binary compatible and freely available SBR also runs in a SPARC Solaris environment

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

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

Figure 1.1 The Lab for this Book

In a Service Provider’s network, the subscribers will typically come in off of DSLAM’s, ONT’s, or WiFi hotspots, possibly through other aggregation devices, and ultimately to the MX via 1- or 10 Gig Ethernets The MX in this capacity is a Broadband Remote Access Server (BRAS - old term), now more commonly referred to as a Broadband Network Gateway (BNG) The subscribers will usually come in via VLAN’s requiring another step in the MX configuration

This VLAN demux is described in Day One: Dynamic Subscriber

Management but as far as understanding the configuration, it’s very

similar

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

The Basic Use Case and Flow

The following ladder diagram and text explains the flows that happen

as a subscriber comes active

Figure 1.2 Ladder Diagram of a New Subscriber Connection

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

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

match, will accept the request The subscriber database will also contain a profile name, the profile name matches a list of attributes to

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

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

Change of Authorization (CoA)

Once a subscriber session has been authorized and the dynamic profile has been applied, the MX issues a RADIUS accounting start message This message contains the two most important attributes used to

identify the subscriber: the Accounting-Session-ID and the

NAS-IP-Address (MX IP address) Any CoA message uses these two attributes

to invoke the CoA Since the Accounting-Session-ID is unique to the

MX, the MX knows which session to change Using the Session-ID is a convention in CoA with the MX, while other device vendors may use different attributes, such as NAS-Port-ID

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

„ action = change speed

„ rate = 10M (Egress-Policy-Name attribute, or firewall filter name

in the MX)

„ Framed-IP-Address = 10.10.10.55 The rate = 10M would actually be a RADIUS attribute corresponding

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

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

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

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

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

IGMP-Enable Enable or disable IGMP on a client interface

LI-Action Traffic mirroring action

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

Service-Statistics Enable or disable statistics for the service

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

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

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

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

MLD-Version MLD protocol version

IGMP-Version IGMP protocol version

IGMP-Immediate-Leave IGMP immediate leave

MLD-Immediate-Leave MLD immediate leave

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

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

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

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

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

CoS-Scheduler-Pmt-Type CoS scheduler parameter types

Chapter 2

Setting Up the MX

Configuring the MX 16

Licensing Requirements 16

Configuring the Loopback Interface 18

Configuring ge-2/2/0 18

Configuring the DHCP Local Server 18

Configuring the Dynamic Profile 20

Checkpoint – Validating the Configuration 21

Adding Firewall Filters to the Configuration 22

Summary 25

This chapter describes the basic setup for a DHCP client to obtain its

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

Configuring the MX

Figure 2.1 shows our simple DHCP client (PC in our case) connected

to the MX The MX has a local DHCP pool assigning addresses 10.10.10.50 through 10.10.10.60 via interface ge-2/0/0.

Figure 2.1 MX Configuration for DHCP Local Server

The steps needed to configure this basic setup are:

„ Configure the loopback interface (using 10.10.10.149/32)

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

„ Configure DHCP local server

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

Licensing Requirements

The MX comes with a 30-day trial license for 1K subscriber sessions, if

this is not sufficient with the equipment in your lab, two licenses will

be required

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

„ 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

Configuring the Loopback Interface

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

loopback address is referred to as using an unnumbered interface,

where the unnumbered interface borrows the ip address from the loopback interface.

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

and Stacked VLAN specific use cases, see Day One: Dynamic

Sub-scriber Management at www.juniper.net/dayone.

Configuring the DHCP Local Server

The DHCP local server configuration is comprised of three pieces: first

is the local address pool with DHCP attributes, second is the attributes controlling the pool, and third is the access profile

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

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

[edit access address-assignment]

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

[edit system services dhcp-local-server]

In this configuration the statement pool-match-order uses the

ip-ad-dress-first to select the DHCP pool to use Authentication is set up to

use the tag foobar, along with MAC address of the client, to create a

user name This is important when RADIUS is used to authorize the

connection The statement dynamic-profile points to the dynamic

profile name that is configured in the next section Also, you can see that the interface ge-2/2/0 is referenced to specify which interfaces will use this DHCP configuration.

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

RADIUS access request.

Configuring the Dynamic Profile

The last configuration piece in setting up the use case for this book is adding the dynamic profile used to create the ipdemux subscriber connection In the preceding configuration [system services dhcp-local-

server] it is specified to use a dynamic profile called IPDemux The

dynamic profile uses $junos variables, and the variables are filled in with values when triggered by packets arriving at the interface

Checkpoint – Validating the Configuration

Okay At this point, the network configuration shown in Figure 2.1 should be active When the DHCP client enables its Ethernet port, the

MX should allocate an IP address from the DHCP pool and build a demux interface The first place to look is on the client PC to see if an

IP address is being assigned Here’s an example from Windows 7:

And the IPv4 address allocated is 10.10.10.57 along with the default gateway of 10.10.10.149 and a DNS server 8.8.8.8 The MAC address

is 00-50-56-BD-00-35, which, when preceded by foobar, should be the

username associated with this subscriber.

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

[edit]

root@Camlab# run show subscribers

Interface IP Address/VLAN ID User Name LS:RI

demux0.1073741886 10.10.10.57 foobar.0050.56bd.0035 default:default

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

To see the MX local DHCP server bindings:

root@Camlab# run show dhcp server binding

IP address Session Id Hardware address Expires State Interface 10.10.10.57 38918 00:50:56:bd:00:35 2027 BOUND ge-2/2/0.0

Using the interface name demux0.1073741886 in the show subscribers

command, details on the actual subscriber can be retrieved:

[edit]

root@Camlab# run show interfaces demux0.1073741886

Logical interface demux0.1073741886 (Index 141076) (SNMP ifIndex 653)

Flags: SNMP-Traps 0x4000 Encapsulation: ENET2

Demux:

Underlying interface: ge-2/2/0.0 (Index 329)

Family Inet Source prefixes, total 1

Prefix: 10.10.10.57/32

Input packets : 15011

Output packets: 25622

Protocol inet, MTU: 1500

Flags: Sendbcast-pkt-to-re, Unnumbered

Donor interface: lo0.0 (Index 321)

TIP There are several other commands you can use to drill down into the

subscriber connection, which you can access using simple Junos help

<?> prompt.

Adding Firewall Filters to the Configuration

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

MORE? Firewall filters are very powerful and our configuration is just using a

small subset, so to get an idea of the kinds of things that can be done,

please see http://www.juniper.net/techpubs/ and search for firewall

filters Also, visit the Day One library at http://www.juniper.net/

dayone for several books that include firewall filter creation.

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

burst-size-limit is a byte count, not bits, as in bandwidth-limit It’s

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

MORE? For a more detailed description on burst-size-limit, please see http://

www.juniper.net/techpubs/ and search for burst-size-limit

With the firewall filters defined, they now get added to the profile, which was configured previously For now, the filter gets added directly by name, using the police-2M as a starting point After the SBR

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

NOTE At this point, the DHCP client needs to be released from its previous

DHCP bindings before the configuration can be committed Junos will not allow a change to a dynamic profile that is in use by a subscriber This is done using the clear command or run clear from the [edit] menu:

clear dhcp server bindings all

After clearing the bindings, the new configuration should commit Starting with Junos 11.4, you can do dynamic profile versioning, which allows changes when subscribers are using a profile.

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

[edit]

root@Camlab# run show subscribers

Interface IP Address/VLAN ID User Name LS:RI

demux0.1073741888 10.10.10.58 foobar.0050.56bd.0035 default:default [edit]

root@Camlab# run show firewall

As the output of the show firewall command shows, filter name

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

Summary

At this point you should have a working DHCP client with ingress and egress firewall filters assigned limiting traffic to 2Mbps You should also have a good understanding of how the MX uses dynamic profiles

in DHCP applications as well as the concepts of firewall filters being used as a policer

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

authoriza-Chapter 3

Adding SBR to the Configuration

Licensing Requirements 28

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

Configuring SBR Text Files 32

Configuring SBR RADIUS Clients, Profiles, and Users 34

Configuring the MX for Radius Authorization 38

Testing the Configuration - Logs 41

Summary 50

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

authori-„ 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: SCM)

SBR-CAR-SCM stands for Session Control Module and allows for CoA/DM, as

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

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

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

Virtual-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 scribed in the SBR install guide (get it here: http://www.juniper.net/

de-techpubs/ and search for Steel Belted Radius Install) If you just want

to install the SBR rpm without the manual, simply load the rpm file into a tmp directory on the Linux server, then execute: yum localin-stall <sbr rpm file name>

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

[root@src-linux RADIUS]# /etc/init.d/iptables stop

iptables: Flushing firewall rules: [ OK ]

iptables: Setting chains to policy ACCEPT: filter [ OK ]

iptables: Unloading modules: [ OK ]

[root@src-linux RADIUS]#

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

chkconfig iptables stop

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

aforemen-„ Enter SBR full license: <SBR-CAR-AAA license>

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

When both licenses are accepted, press the Enter key and the configure script continues For most of the configuration prompts the default is

acceptable (For more information on each of the prompts see the SBR

Installation Guide.) For this book, just make sure it’s a <new>

installa-tion, and enable the autoboot script (these are default)

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

Start SBR by navigating to the /opt/JNPRsbr/RADIUS directory – this

is the default directory where most of the configuration work is done From this directory run the sbrd script as follows:

[root@src-linux RADIUS]# cd /opt/JNPRsbr/RADIUS/

[root@src-linux RADIUS]# /sbrd start

Starting RADIUS server processes

RADIUS: Process ID of daemon is 15763

RADIUS: Starting DCF system

[root@src-linux RADIUS]# RADIUS:

RADIUS: Steel-Belted Radius licenses

RADIUS: License String: Additional Info:

RADIUS: 08200011021412490001000117107879 Run license - expires 6/3/2013 - 1k

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

Once SBR has started successfully, bring up the admin GUI interface

from Internet Explorer or Firefox by navigating to

http://<server-ad-dress>:1812.

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

NOTE SBR admin GUI runs on IE and Firefox with java enabled If you have

trouble launching the admin GUI, but can get to the web server, check the java configurations.

Configuring SBR Text Files

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

;LogDir = <file system location>

;The following setting will display the system information at rollover

;SysInfoOnRollover = yes

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

NOTE Verbose logging should not be used in a production network because

of performance considerations.

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

[Addresses]

; This section controls which IP addresses the server will listen on for

; incoming RADIUS packets By default, the server will use DNS (and DNSv6 if

; IPv6 is enabled) to configure all local IP addresses except for the following:

; IPv4/IPv6 loopback, IPv6 link local (DEPRECATED), IPv6 site local (DEPRECATED)

; Alternatively, one or more IP addresses may be specified explicitly, each on

; a separate line, in which case only the specified addresses will be configured

; Zero or more of the following AutoConfigure directives may also be specified:

;AutoConfigureIPv4 ; Use DNS to configure all local IPv4 addresses

;AutoConfigureIPv6 ; Use DNSv6 to configure all local IPv6 addresses

10.10.10.102

The Addresses section is simply used to specify the IP addresses (ports

on the server) that are needed for the RADIUS process to listen on In a typical VM installation there’s only one port, so configuring the address is not needed In multiple NIC installations, there may be a requirement not to listen on certain ports If that’s the case, simply type

in the IP addresses that you need RADIUS to listen to on the server, as shown above in bold.

vendor.ini

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

is the same for either an ERX or a MX running subscriber ment

manage-NOTE It’s important to note that SBR only processes RADIUS packets using

the dictionary associated with the product listed in vendor.ini, along with the standard RADIUS.dct attributes.

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

vendor-product = Unisphere MX with JUNOS v11.2

After the edits are done to the text files, restart or hup the sbr process

as root.in the /opt/JNPRsbr/RADIUS directory:

./sbrd restart

or

./sbrd hup

Configuring SBR RADIUS Clients, Profiles, and Users

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

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 won’t work with CoA, so each client is configured specifically).

After clicking on Add, the Edit RADIUS CLIENT panel appears Choose a name and set the address of the MX, 10.10.10.101 in our

case, and testing123 as a shared secret (this is defaulted as masked)

Select the Make or Model as was entered in your vendor.ini Leave it

3799 in the RFC 3576 CoA/DM port field, and use the same shared secret that RADIUS uses

When you’re done click OK, and the client is added There’s no need

to hup or restart with changes you make in the admin GUI.

Profiles

In SBR, profiles are simply lists of attributes that either are expected to

be received in an access request (checklist) or returned in an access

accept (return list) In the use case for this book checklists won’t be

used However, the attributes corresponding to the police-2M firewall filter defined in the MX will be set up in the return list This profile will

be called slow – for obvious reasons

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

„ Unisphere-Ingress-Policy-Name

„ Unishphere-Egress-Policy-Name

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

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

Give the profile the name slow and click on the Return List tab in the

Attributes detail Click on Add and look for

Unisphere-Ingress-Policy-Name and input a value of police-2M, and then do the same for

Unisphere-Egress-Policy-Name When you select Add in the attribute list, the list contains attributes that are in the RADIUS.dct file as well

as the unisphereMX11-2.dct file configured in vendor.ini Only

attributes that are valid in a return list are shown

MORE? There are many attributes corresponding to dynamic profile and Class

of Service settings in the MX discussed in Chapter 1

Native Users

A user database that is internal to the SBR server is called native users

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

The native user’s panel in SBR admin GUI allows you to add users/

password and profiles for each subscriber Profiles are pointers to lists

of attributes that you want returned with the access accept message

Looking back at Chapter 2, the DHCP subscriber was given a user

name of foobar.0050.56bd.0035, built from user-prefix foobar, and

the mac-address of the DHCP client:

previously, thus indicating the 2M policers defined in the MX.

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

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

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

Configuring the MX for Radius Authorization

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

To configure the MX to talk to RADIUS let’s start with adding the

password juniper to the user-name The password field must be present

in a RADIUS access request, even though all users will share the same password The password in this case is not technically authentication,

just authorization and compliance to RFCs It’s called authentication

server in the MX, but again, technically it’s authorization of the

user-name This configuration is done in the [edit system services dhcp-local-server] hierarchy:

Figure 3.1 Configure the MX to Request Authorization

[edit system services dhcp-local-server]

root@Camlab# set authentication password juniper

[edit system services dhcp-local-server]

root@Camlab# show

traceoptions { ## Warning: 'traceoptions' is deprecated

file dhcp-server-msgs.log size 10m world-readable;

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]

Under the RADIUS-server stanza, the secret corresponds to the same

shared secret entered on SBR – testing123 It’s masked in Junos

Accounting and authentication have been configured Accounting needs to be configured since SBR builds its current session table based

on accounting and not authorization There is an update-interval set to

10 minutes, which means the MX will send interim accounting updates

at that interval for the duration of the session When the MX generates

an accounting packet (start/stop or interim), it will include an attribute called accounting-session-id This attribute value is what SBR and the

MX will use to generate CoA messages later in the book It’s essentially

a unique value for this subscriber session.

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