Sunday, August 3, 2014

Using daloRadius in GNS3 to demo an ISP's bandwidth control using PPPoE

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.



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.