Previously, I had written notes on how to build your own
daloRadius server on a CentOS 6 virtual machine. Today, I'm going to
demonstrate how an ISP might use radius to control the bandwidth of
its customers with a Cisco router configured as a network access
server (NAS)/PPPoE server.
First, let me show you how powerful this can be, by giving you a scenario that will make the job of modifying a customer's circuit to be very easy. Then I will show you how to set it all up.
Scenario:
We will pretend that we have a small ISP network with the below topology, with R1 acting as the ISP, R2 acting as the client using PPPoE. The customer, username 'cisco', is using the C Rate plan from the ISP. This gives the customer a download speed of 512 Kbps and an upload speed of 128 Kbps. The customer has decided to upgrade to the B Rate, which doubles the speed in both directions.
The customer calls the service fulfillment desk and requests the upgrade. Rather than having to check the customer's account and put in an order with the network administrator to change settings on the Cisco router, daloRadius gives the customer service representative the power to make the change in billing and to the circuit itself
You can see below the capture of the list of users, in the list of users, (found by navigating to MANAGEMENT->USERS->LIST USERS) you can see that cisco is in the group 'C RATE'. The radius server will pass special attributes to the ISP's router when the customer logs in, called reply attributes, and with that information the router will perform a specific way depending on the attributes.
First, let me show you how powerful this can be, by giving you a scenario that will make the job of modifying a customer's circuit to be very easy. Then I will show you how to set it all up.
Scenario:
We will pretend that we have a small ISP network with the below topology, with R1 acting as the ISP, R2 acting as the client using PPPoE. The customer, username 'cisco', is using the C Rate plan from the ISP. This gives the customer a download speed of 512 Kbps and an upload speed of 128 Kbps. The customer has decided to upgrade to the B Rate, which doubles the speed in both directions.
The customer calls the service fulfillment desk and requests the upgrade. Rather than having to check the customer's account and put in an order with the network administrator to change settings on the Cisco router, daloRadius gives the customer service representative the power to make the change in billing and to the circuit itself
You can see below the capture of the list of users, in the list of users, (found by navigating to MANAGEMENT->USERS->LIST USERS) you can see that cisco is in the group 'C RATE'. The radius server will pass special attributes to the ISP's router when the customer logs in, called reply attributes, and with that information the router will perform a specific way depending on the attributes.
The C RATE group's
reply attributes can be seen below (found by navigating to
MANAGEMENT->Profiles->Select Profile->Reply Attributes. The
important attributes for this demonstration are:
Cisco:Cisco-avpair =
"ip:sub-policy-In=POLICE-128K"
Cisco:Cisco-avpair
+= "ip:sub-policy-Out=POLICE-512K"
These values will be
passed to the ISP's router any time a user in the C RATE group logs
in. A Cisco router will apply these policy maps to limit the
bandwidth of the customer on the virtual-access interface in PPPoE
that is created when the customer connects, thus delivering that
service plan.
First I am going to
demonstrate the customer's current plan with an extended ping across
R1 before he upgrades.
R2#ping 172.16.1.55
size 1400 repeat 100
Type escape sequence
to abort.
Sending 100,
1400-byte ICMP Echos to 172.16.1.55, timeout is 2 seconds:
!!!!.!!!.!!!.!!!!!.!!!!.!!!!.!!!.!!!.!!!!.!!!!.!!!.!!!!.!!!!.!!!!.!!!!
.!!!.!!!!.!!!!.!!!!.!!!!.!!!.!
Success rate is 79
percent (79/100), round-trip min/avg/max = 24/37/64 ms
You can see there a
quite a lot of drops. This is because the ISP is policing the
inbound traffic all the way down to 128 Kbps.
You can see these
drops from the ISP router as well.
R1#sho policy-map
int virtual-access 3
Virtual-Access3
Service-policy
input: POLICE-128K
Class-map:
class-default (match-any)
100 packets,
140200 bytes
5 minute
offered rate 6000 bps, drop rate 0 bps
Match: any
police:
cir 128000
bps, bc 4000 bytes
conformed 79
packets, 110758 bytes; actions:
transmit
exceeded 21
packets, 29442 bytes; actions:
drop
conformed
7000 bps, exceed 0 bps
Service-policy
output: POLICE-512K
Class-map:
class-default (match-any)
119 packets,
112898 bytes
5 minute
offered rate 6000 bps, drop rate 0 bps
Match: any
police:
cir 512000
bps, bc 16000 bytes
conformed 79
packets, 112338 bytes; actions:
transmit
exceeded 0
packets, 0 bytes; actions:
drop
conformed
8000 bps, exceed 0 bps
Now the customer
calls in for an upgrade, and the service desk upgrades the account by
going to MANAGEMENT->USERS->EDIT USER->GROUPS and changes
the group to B RATE below.
With the upgrade
complete from their end, the service desk asks the customer to reboot
their router and the customer will observe the new data rate. Rather
than perform the reboot, the customer recycles the Dialer 1 interface
on their router below:
R2#conf t
Enter configuration
commands, one per line. End with CNTL/Z.
R2(config)#int
dialer 1
R2(config-if)#shut
R2(config-if)#
*Mar 1
00:12:01.051: %DIALER-6-UNBIND: Interface Vi2 unbound from profile
Di1
*Mar 1
00:12:01.063: Di1 DDR: dialer shutdown complete
R2(config-if)#
*Mar 1
00:12:01.291: %LINK-3-UPDOWN: Interface Virtual-Access2, changed
state to down
R2(config-if)#
*Mar 1
00:12:02.039: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access2, changed state to down
R2(config-if)#
*Mar 1
00:12:03.067: %LINK-5-CHANGED: Interface Dialer1, changed state to
administratively down
R2(config-if)#no
shut
R2(config-if)#^Z
R2#
*Mar 1
00:13:00.731: %LINK-3-UPDOWN: Interface Dialer1, changed state to up
R2#
*Mar 1
00:13:02.083: %SYS-5-CONFIG_I: Configured from console by console
R2#
*Mar 1
00:13:03.851: %DIALER-6-BIND: Interface Vi2 bound to profile Di1
R2#
*Mar 1
00:13:03.871: %LINK-3-UPDOWN: Interface Virtual-Access2, changed
state to up
R2#
*Mar 1
00:13:05.311: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access2, changed state to up
R2#ping 172.16.1.55
size 1400 repeat 100
Type escape sequence
to abort.
Sending 100,
1400-byte ICMP Echos to 172.16.1.55, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!
!!!!!!!!!!.!!!!!!!!!!!!!!!!!!.
Success rate is 95
percent (95/100), round-trip min/avg/max = 16/32/56 ms
So the customer went
from 79 percent success to 95 percent success.
With some debugs,
and show commands you can also observe the changes from the ISP
router below:
R1#debug aaa
authorization
AAA Authorization
debugging is on
R1#debug aaa
per-user
AAA Per-user
attributes debugging is on
R1#
*Mar 1
00:12:02.527: %LINK-3-UPDOWN: Interface Virtual-Access3, changed
state to down
*Mar 1
00:12:03.527: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access3, changed state to down
R1#
*Mar 1
00:13:05.167: AAA/BIND(00000005): Bind i/f Virtual-Template1
*Mar 1
00:13:05.451: ppp3 PPP/AAA: Check Attr: Framed-Protocol
*Mar 1
00:13:05.451: ppp3 PPP/AAA: Check Attr: link-compression: Peruser
Full Vaccess
*Mar 1
00:13:05.455: ppp3 PPP/AAA: Check Attr: sub-policy-In: Peruser
*Mar 1
00:13:05.459: ppp3 PPP/AAA: Check Attr: sub-policy-Out: Peruser
*Mar 1
00:13:05.463: ppp3 PPP/AAA: Check Attr: service-type
*Mar 1
00:13:05.523: AAA/BIND(00000005): Bind i/f Virtual-Access3
*Mar 1
00:13:05.535: %LINK-3-UPDOWN: Interface Virtual-Access3, changed
state to up
*Mar 1
00:13:05.555: Vi3 AAA/AUTHOR/LCP: Process Author
*Mar 1
00:13:05.559: Vi3 AAA/AUTHOR/LCP: Process Attr: link-compression
*Mar 1
00:13:05.563: AAA/AUTHOR: Processing PerUser AV link-compression
*Mar 1
00:13:05.563: Vi3 AAA/AUTHOR/LCP: Process Attr: service-type
*Mar 1
00:13:05.567: Vi3 AAA/AUTHOR/LCP: IF_config:
ip tcp
header-compression
*Mar 1
00:13:05.635: Vi3 AAA/AUTHOR/IPCP: FSM authorization not needed
*Mar 1
00:13:05.639: Vi3 AAA/AUTHOR/FSM: We can start IPCP
*Mar 1
00:13:05.643: Vi3 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we
want 0.0.0.0
*Mar 1
00:13:05.647: Vi3 AAA/AUTHOR/IPCP: Processing AV sub-policy-In
*Mar 1
00:13:05.651: Vi3 AAA/AUTHOR/IPCP: Processing AV sub-policy-Out
*Mar 1
00:13:05.651: Vi3 AAA/AUTHOR/IPCP: Authorization succeeded
*Mar 1
00:13:05.655: Vi3 AAA/AUTHOR/IPCP: Done. Her address 0.0.0.0, we
want 0.0.0.0
*Mar 1
00:13:05.771: AAA/AUTHOR: Processing PerUser AV sub-policy-In
*Mar 1
00:13:05.827: Vi3 AAA/PER-USER: Set input QoS policy to POLICE-256K
*Mar 1
00:13:05.827: AAA/AUTHOR: Processing PerUser AV sub-policy-Out
*Mar 1
00:13:05.867: Vi3 AAA/PER-USER: Set output QoS policy to POLICE-1024K
*Mar 1
00:13:06.535: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access3, changed state to up
R1#
R1#sho policy-map
int virtual-access 3
Virtual-Access3
Service-policy
input: POLICE-256K
Class-map:
class-default (match-any)
100 packets,
140200 bytes
5 minute
offered rate 2000 bps, drop rate 0 bps
Match: any
police:
cir 256000
bps, bc 8000 bytes
conformed 95
packets, 133190 bytes; actions:
transmit
exceeded 5
packets, 7010 bytes; actions:
drop
conformed
12000 bps, exceed 0 bps
Service-policy
output: POLICE-1024K
Class-map:
class-default (match-any)
103 packets,
135202 bytes
5 minute
offered rate 2000 bps, drop rate 0 bps
Match: any
police:
cir
1024000 bps, bc 32000 bytes
conformed 95
packets, 135090 bytes; actions:
transmit
exceeded 0
packets, 0 bytes; actions:
drop
conformed
12000 bps, exceed 0 bps
Note: if the
customer was concerned with the dropped packets, he could configure
traffic shaping (a different method of controlling bandwidth that
will hold onto packets, queue, until the average datarate has once
again fallen below the given rate) to the ISP with a configuration
like the one below:
policy-map SHAPE-OUT
class class-default
shape average
256000
int fa0/1
service-policy
output SHAPE-OUT
R2#ping 172.16.1.55
size 1400 repeat 100
*Mar 1
00:28:22.111: %SYS-5-CONFIG_I: Configured from console by console
R2#ping 172.16.1.55
size 1400 repeat 100
Type escape sequence
to abort.
Sending 100,
1400-byte ICMP Echos to 172.16.1.55, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100
percent (100/100), round-trip min/avg/max = 24/42/72 ms
Now the customer has
an improved connection, without getting the ISP's network staff
involved and delivering the upgrade to the customer immediately. The
ISP can also benefit by having the accounting of radius tied into the
same system as billing by updating the billing rate at the same time,
or even by having bandwidth on demand services such as billing per
packet or per byte. Thus illustrating some of the advantages of
PPPoE for the ISP. Now, its time to start over, with a blank
configuration of R1 and R2 and with an empty database of daloRadius
and show under the hood a little.
I am going to start
assuming you have already created the topology in GNS3 and you are
running GNS3 as administrator so you could do the cloud connection to
your VirtualBox VM and the VM has another connection to your physical
adapter so that you can login to the webpage of daloRadius through
that interface as outlined in my notes:
If you are using the
VM appliance from daloRadius,
http://sourceforge.net/projects/daloradius/files/daloradius/daloRADIUS%20VM/,
you may want to look over my notes anyways so that you configure the
VM with the right IP addresses.
Assuming R1 is
connected to the radius server on FastEthernet Fa0/0, I am going to
gain connectivity to the server which has the IP address of
172.16.1.55 with:
config t
interface
FastEthernet0/0
ip address
172.16.1.1 255.255.255.0
no shutdown
end
R1#ping 172.16.1.55
Type escape sequence
to abort.
Sending 5, 100-byte
ICMP Echos to 172.16.1.55, timeout is 2 seconds:
!!!!!
Success rate is 100
percent (5/5), round-trip min/avg/max = 8/16/32 ms
Now, it's time to
also configure a loopback interface on R1 and ensure connectivity to
the radius server via that IP. This is a common practice for router
services, because routers often have many IP addresses and many
routes to a destination server, we will end up specifying a loopback
interface that will be used for the radius service, that way the
radius server will allow only radius messages from that IP and it
will not matter which route, if there is more than 1, the router's
messages to the radius server takes.
config t
interface Loopback1
ip address
172.25.25.25 255.255.255.255
end
R1#ping 172.16.1.55
source 172.25.25.25
Type escape sequence
to abort.
Sending 5, 100-byte
ICMP Echos to 172.16.1.55, timeout is 2 seconds:
Packet sent with a
source address of 172.25.25.25
!!!!!
Success rate is 100
percent (5/5), round-trip min/avg/max = 8/16/44 ms
If the ping is
successful, then we can configure R1 to authenticate telnet and SSH
users off of the radius server, and as a precaution, we will create a
backup account on the router that will only work when the router
cannot talk to the radius server. The following configuration will
configure AAA to use our radius server:
config t
radius-server host
172.16.1.55 auth-port 1812 acct-port 1813 key cisco$$$
ip radius
source-interface Loopback1
aaa group server
radius RADIUS-ACT
server 172.16.1.55
auth-port 1812 acct-port 1813
aaa authentication
login default group RADIUS-ACT local
aaa authorization
exec default group RADIUS-ACT local
aaa accounting exec
default start-stop group RADIUS-ACT
username backup priv
15 secret backup!!!
Notice that we
configured “radius-server” with the IP address of the
server, the UDP ports to use, and a key. This key is important as it
is what the radius server uses to ensure, along with the source IP
(loopback 1), the NAS/router, is an authorized router.
To configure a NAS
in daloRadius login to the administrative interface on your physical
connection at http://192.168.1.55
and goto MANAGEMENT->NAS->NEW NAS and add in the NAS IP of the
loopback, 172.25.25.25, the NAS Secret (Key), cisco$$$, the NAS type,
cisco, and a NAS shortname, as below.
You will also need
to create a user account to login to the router with. I am using the
name, steve. Create two accounts, 1 for login, and 1 later for
PPPoE, called cisco. Fill in the username and passwords only for
now. This can be found under MANAGEMENT->USERS->NEW USER. Then
create a new group, called 'CISCO-LEVEL15', under
MANAGEMENT->PROFILES->NEW PROFILES. For the creating of the
group, you will need to create an attribute. Fill out the new
profile information as it shows below:
Profile Name:
CISCO-LEVEL15
Quickly Locate
attribute with autocomplete input: Service-Type
Add Attribute
Select from the
Value drop down: NAS-Prompt-User
The select Apply
The go back and edit
the profile and add another attribute by selecting the profile->Edit
profile->Attributes and fill in to following:
Vendor: Cisco
Attribute:Cisco
AV-Pair
Add Attributes
Value:”shell:priv-lvl=15”
without quotes
Op:=
Target:reply
Apply
Modify your login
account so that it can login to the router by doing to following:
MANAGEMENT->USERS->TYPE 'STEVE' UNDER EDIT USERS-> EDIT
USER->GROUPS->GROUP #1->Select CISCO-LEVEL15.
This is the proper
configuration to allow you to telnet to 172.25.25.25 from R1 back
into itself and login with the 'steve' account. It will, however,
not work, only the backup account will login. This is because the
daloRADIUS server is comprised of 3 services. SSH into your server
and run the command “chkconfig --list | egrep
'httpd|radius|mysql', you will see the following services running:
[root@localhost ~]#
chkconfig --list | egrep 'httpd|radius|mysql'
httpd
0:off 1:off 2:on 3:on 4:on 5:on 6:off
mysqld
0:off 1:off 2:on 3:on 4:on 5:on 6:off
radiusd
0:off 1:off 2:on 3:on 4:on 5:on 6:off
Httpd is the apache
web server that displays daloRadius. DaloRadius php pages interface
with the MySQL service to perform configuration and obtain
information. Radiusd is the freeradius 2 service configured to use
the same MySQL database that daloRadius is using. Freeradius will
read the configuration information set by daloRadius, and daloRadius
will read the accounting information created by freeradius. The
problem turns out to be that freeradius 2 will only add or remove a
NAS at service startup, users and groups can be modified at anytime.
You can also confirm the problem with “tail /var/log/radius”:
Wed Jul 30 18:13:50
2014 : Info: rlm_sql (sql): Connected new DB handle, #3
Wed Jul 30 18:13:50
2014 : Info: rlm_sql (sql): Attempting to connect rlm_sql_mysql #4
Wed Jul 30 18:13:50
2014 : Info: rlm_sql_mysql: Starting connect to MySQL server for #4
Wed Jul 30 18:13:50
2014 : Info: rlm_sql (sql): Connected new DB handle, #4
Wed Jul 30 18:13:50
2014 : Info: Loaded virtual server <default>
Wed Jul 30 18:13:50
2014 : Info: Loaded virtual server inner-tunnel
Wed Jul 30 18:13:50
2014 : Info: ... adding new socket proxy address * port 54696
Wed Jul 30 18:13:50
2014 : Info: Ready to process requests.
Wed Jul 30 19:48:36
2014 : Error: Ignoring request to authentication address * port 1812
from unknown client 172.25.25.25 port 1645
Wed Jul 30 19:48:41
2014 : Error: Ignoring request to authentication address * port 1812
from unknown client 172.25.25.25 port 1645
Restart the service
with “service radiusd restart'. At this point, the account
'steve' can login to telnet, 'cisco', the PPP account cannot, neither
can 'backup', the local account, because radius is responding.
We went through the
steps of configuring R1 to authenticate login users via radius as an
easier first step to ensure the radius server was working, also to
illustrate how attributes can be used to set different users to have
different types of privileges on for different types of services.
With login access working, we can now focus our attention on PPPoE.
As mentioned before
PPPoE is popular with ISPs. This is because of the large amount of
flexibility and integration that it can offer in conjunction with a
radius server. It is also because PPP (Point to Point Protocol) was
already heavily used prior to the popularity of broadband Internet
services. PPP was used largely over serial and dial up links and had
many capabilities, some similar to those demonstrated in this
article, others like the binding of slow WAN links for load
balancing, its own frame type that supported a multiprotocol
environment, and numerous authentication and compression types to
name a few. Some of these features are no longer used, and some of
these are expanded.
PPPoE, PPP over
Ethernet, was a market driven protocol. ISP's needed to have the
same type of back end compatibility to support their customers with
broadband as they had with dialup. Thus, PPPoE was created to meet
that requirement, by creating a point to point frame that road over
the Ethernet frame, establishing a logical link to the NAS/PPPoE
server deciding what level of service the customer would obtain and
the accounting so that flexible (in the ISP's mind) billing
structures could be created. 10 years ago, when I was working for an
ISP, this is why I wanted to implement PPPoE over our broadband
services; a project I was not able to realize before moving onto
other projects.
In my topology R1,
the ISP, connects to R2, the customer, via FastEthernet0/1. My
configuration to authenticate the PPPoE users is as follows:
aaa accounting
delay-start
aaa authentication
ppp default if-needed group RADIUS-ACT local
aaa authorization
network default group RADIUS-ACT local
aaa accounting
network default start-stop group RADIUS-ACT
aaa accounting
update periodic 5
bba-group pppoe
global
virtual-template 1
interface fa0/1
pppoe enable group
global
ip address
172.30.0.1 255.255.0.0
no shut
interface
Virtual-Template1
mtu 1492
ip unnumbered
FastEthernet0/1
peer default ip
address pool GLOBALPOOL
ppp authentication
chap
ip local pool
GLOBALPOOL 172.30.0.2 172.30.127.255
The configuration of
R2 to be a PPPoE client is:
interface
FastEthernet0/1
mtu 1492
pppoe enable
pppoe-client
dial-pool-number 1
no shut
interface Dialer1
ip address
negotiated
encapsulation ppp
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication
chap callin
ppp chap hostname
cisco
ppp chap password
test$$$
ip route 0.0.0.0
0.0.0.0 Dialer1
If you configured
the radius user 'cisco' with the password 'test$$$', you should find
that R2 obtains an IP address and can ping all the way to the radius
server 172.16.1.55, without adding any attributes. We will however,
start by adding the recommended attributes of:
Service-Type =
Framed
Framed-Protocol =
PPP
Use these to create
a profile PPPoE under MANAGEMENT->PROFILES->NEW PROFILE and
EDIT PROFILE to add the second attributes, then assign the cisco user
to that group, so the group looks the same as the one below.
At this point you
should feel comfortable creating profiles with attributes. For the
final lab, you can create a C RATE and a B RATE profile that is the
same as the example at the very beginning with the attributes:
C RATE
Service-Type =
Framed
Framed-Protocol =
PPP
Cisco:Cisco-avpair =
"ip:sub-policy-In=POLICE-128K"
Cisco:Cisco-avpair
+= "ip:sub-policy-Out=POLICE-512K"
B RATE
Service-Type =
Framed
Framed-Protocol =
PPP
Cisco:Cisco-avpair =
"ip:sub-policy-In=POLICE-256K"
Cisco:Cisco-avpair
+= "ip:sub-policy-Out=POLICE-1024K"
You will also have
to add the policy maps to R1 with:
policy-map
POLICE-128K
class class-default
police 128000
policy-map
POLICE-256K
class class-default
police 256000
policy-map
POLICE-512K
class class-default
police 512000
policy-map
POLICE-1024K
class class-default
police 1024000
It is important that
you use the += value for the second Cisco AV pair attribute to add in
the outbound policy. It is also important to ensure the exact policy
name is used in this attribute.
I hope you have fun
with this lab, or can find it useful. This was kind of a project
unfinished for me, but I really enjoyed it.
