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:

http://ephemeralportal.blogspot.jp/2014/07/installing-daloradius-centos-6.html

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.

Installing DaloRadius (CentOS 6, Freeradius2, and MySQL) for AAA in GNS3

I've been wanting to demonstrate AAA for SSH login, PPPoE, and dot1x a while. Its not as fun to create a and have such a large part of the lab work like authentication, plus I like knowing the open source solutions out there. I decided to go with DaloRadius, http://www.daloradius.com/, because it has a fairly clean GUI and integrated with Freeradius. CentOS was chosen because Redhat is often the Linux of choice for most enterprises but soon found out the the latest CentOS, was using very updated versions of Freeradius and MySQL that DaloRadius was not updated to handle.

The server will be run in VirtualBox, a free version of Vmware, from a Windows 7 platform and connect to the web gui via the browser of my real computer then on another virtual NIC tie the server into GNS3 to interface with routers. You could also use real routers and switches of of your real NIC if you were to connect via the bridged adapter.

Most of the build details below were similar to the instructions for CentOS that I found here,

http://www.howtoforge.com/authentication-authorization-and-accounting-with-freeradius-and-mysql-backend-and-webbased-management-with-daloradius. The instructions had a few errors, was a little out-dated, and left out steps like fixing selinux context labels, unblocking ports in iptables, and enabling services at startup. It may, however, go into better detail on some of the steps than I will, so please feel free to refer to it and the INSTALL file in the DaloRadius source code. CLI commands will be in bold, code in italics. I will also leave out things like how to use vi to edit files, the main goal is record the settings used to be able to get DaloRadius working on CentOS 6.

A. Downloads

1. Download latest VirtualBox and extension pack (4.3.14 would not launch VMs because a bug between it and many types of antivirus)
   http://download.virtualbox.org/virtualbox/4.3.12/VirtualBox-4.3.12-93733-Win.exe
   http://download.virtualbox.org/virtualbox/4.3.12/Oracle_VM_VirtualBox_Extension_Pack-4.3.12-93733.vbox-extpack
2. Download the latest GNS3
   http://sourceforge.net/projects/gns-3/files/GNS3/0.8.7/GNS3-0.8.7-all-in-one.exe/download
3. Download the latest CentOS 6 (torrent)
   http://ftp.nara.wide.ad.jp/pub/Linux/centos/6.5/isos/x86_64/CentOS-6.5-x86_64-bin-DVD1to2.torrent
4. Download the latest IOS for a Cisco 3745
   http://software.cisco.com/download/release.html?mdfid=273764423&flowid=7314&softwareid=280805680&release=12.4.25d&relind=AVAILABLE&rellifecycle=MD&reltype=latest

I am running: c3725-adventerprisek9_ivs-mz.124-15.T14.bin

B. Install Supervisors

1. Install VirtualBox (Yes and next to all options) and reboot.
2. Install the VirtualBox extension pack.
3. Install GNS SuperPutty was not checked as an option, I did not select it. Otherwise installed with Yes and next to all options. I had to uninstall the old WinPCap and Wireshark, this was done for me by following the installer.

C. Create Server Virtual Machine

1. Open VirtualBox
2. Click the "New" Icon

• Name the VM -> Set type to Linux -> Set version to Red Hat (bit) -> Next
• Set Memory size -> 512Mb -> Next
• Create a virtual hard drive now -> Next
• Select file type VDI -> Next
• Set storage -> Dynamically allocated -> Next
• Set file location and size -> 8 GB -> Create

3. Right click the VM. Choose settings.

• Network -> Adapter 1 -> Change to bridged
• Adapter 2 -> Enable Network Adapter -> Host Only
• OK

4. Click the "Start" icon in Virtual Box

• Select start-up disk -> Set to the first iso of CentOS you downloaded - Start
• Install or upgrade an existing system (Right CTRL button will release the keyboard and
• mouse from the VM}
• Skip test.
• If you used my memory settings you will get the text version of the install.
• OK -> English -> us -> Re-initialize
• Uncheck System clock uses UTC and select your timezone -> OK
• Set your root password -> OK
• Use entire drive -> OK -> Write changes to disk
• The system will now install and prompt you for reboot

D. Prepping the VM

1. Login and set up networking for updates and management of the VM (eth0/bridged)

• Login with the root account you created.
• vi /etc/sysconfig/network-scripts/ifcfg-eth0 -> Change ONBOOT=yes, BOOTPROTO=static
• Set the a static IP address to something on the same subnet as your physical NIC.
  IPADDR=192.168.1.55
  NETMASK=255.255.255.0
  GATEWAY=192.168.1.1
  Save and quit.
• vi /etc/resolv.conf -> Set your dns
  nameserver 8.8.8.8
  nameserver 4.2.2.2
  Save and quit.
• service network restart

2. Login to the VM via putty from your host Windows machine, and update the OS.

• yum update -y
• shutdown -r now

3. Restart your putty session and setup guest editions for the VM.

• yum install gcc kernel-devel perl -y
• Goto the Virtualbox VM window and select Devices -> Insert Guest Additions CD Image
• mkdir /media/cdrom
• mount /dev/cdrom /media/cdrom
• /media/cdrom/VboxLinuxAdditions.run -> All additions should run but the X windows addition.

E. Install Freeradius, Apache, and DaloRadius; minus the configuration to make them work together.

1. Install Freeradius, wget, and man pages

• yum install freeradius freeradius-mysql freeradius-utils freeradius-libs mysql-server wget man -y
• chkconfig mysqld on
• chkconfig radiusd on

2. Install Apache, php, and pear

• yum install httpd php php-mysql php-pear php-gd php-pear-DB php-dba -y
• chkconfig httpd on
• pear install db -> (takes a long time)

3. Unblock the incoming ports

• vi /etc/sysconfig/iptables -> Insert the following lines directly above the permit for port 22.
  -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
  -A INPUT -m state --state NEW -m udp -p udp --dport 1812 -j ACCEPT
  -A INPUT -m state --state NEW -m udp -p udp --dport 1813 -j ACCEPT
  save and quit
• service iptables restart

4. Download and install Daloradius

• wget http://downloads.sourceforge.net/project/daloradius/daloradius/daloradius0.9-9/daloradius-0.9-9.tar.gz
• (wget with url was one command line)
• tar zxvf daloradius-0.9-9.tar.gz
• mv daloradius-0.9-9 /var/www -v
• chown apache:apache /var/www/daloradius-0.9-9/ -R
• chcon -R -t httpd_sys_content_t /var/www/daloradius-0.9-9/

F. Configure Freeradius to work with MySQL, DaloRadius to work with MySQL, and DaloRadius to be hosted in Apache

1. Configure Freeradius to work with MySQL

• service mysqld start
• mysqladmin -u root password complexpassword
• mysql -u root -p -> will be prompted for the "complex password" you just created
  CREATE DATABASE radiusdb;
  GRANT ALL ON radiusdb.* TO freeradius@localhost IDENTIFIED BY "freeradpass";
  exit;
• mysql -u root -p radiusdb < /var/www/daloradius-0.9-9/contrib/db/fr2-mysql-daloradius-and-freeradius.sql
• mysql -u root -p
  use radiusdb;
  show tables;
  You should see 35 rows in set
  quit;
• vi /etc/raddb/radiusd.conf -> Search & uncomment this line $INCLUDE sql.conf -> save and quit
• vi /etc/raddb/sites-enabled/default -> uncomment sql from authorize and accounting sections -> save and quit
• vi /etc/raddb/sql.conf ->
  uncomment readclients = yeschange login = "radius" to the account you created (freeradius) ->
  change password = "radpass" to the password you created (freeradpass) ->
  change radius_db = "radius" to radius_db = "radiusdb" ->
  save and quit.
• service radiusd start

2. Configure DaloRadius to work with MySQL

• mysql -u root -p
  GRANT ALL ON radiusdb.* TO dalo@localhost IDENTIFIED BY "dalopassword";
  exit;
• vi /var/www/daloradius-0.9-9/library/daloradius.conf.php -> Set the following values:
  $configValues['CONFIG_DB_USER'] = 'dalo';
  $configValues['CONFIG_DB_PASS'] = 'dalopassword';
  $configValues['CONFIG_DB_NAME'] = 'radiusdb';
  Save and quit.
• touch /tmp/daloradius.log
• chown apache:apache /tmp/daloradius.log

3. Configure DaloRadius to be hosted in Apache

vi /etc/httpd/conf/httpd.conf -> Add the following to the end of the file where 192.168.1.100 is the IP address of your host computer or the IP addresses you would like to administer DaloRadius:
Alias /myradius "/var/www/daloradius-0.9-9/"
<Directory /var/www/daloradius-0.9-9/>
Options None
order allow,deny
allow from 127.0.0.1
allow from 192.168.1.100
</Directory>
Save and quit.
• service httpd start

4. I also changed the security context of selinux for the DaloRadius folder with the following, but found out I had another issue.

• yum install policycoreutils-python -t
• semanage fcontext -a -t public_content_rw_t '/var/www/daloradius-0.9-9/(/.*)?'
• restorecon /var/www/daloradius-0.9-9/
• chcon -R -t httpd_sys_content_t /var/www/daloradius-0.9-9/

5. You should now be able to browse into your VM at http://192.168.1.55/myradius and login as administrator, password radius.

G. Put your system on the same network as a router.

1. vi /etc/sysconfig/network-scripts/ifcfg-eth0 -> remove the GATEWAY line.
2. vi /etc/sysconfig/network-scripts/ifcfg-eth1 -> Set up your network
3. Set the a static IP address to something on the same subnet as your physical NIC.
   ONBOOT=yes
   BOOTPROTO=static
   IPADDR=172.16.1.55
   NETMASK=255.255.255.0
   GATEWAY=172.16.1.1
   Save and quit.
4. service network restart
5. Open GNS3 as an administrator.

• Configure a router to use your IOS under Edit -> IOS and Hypervisors
• Configure the IDLE timeout, mine for the image above was 0x80736f38
• Add a router and a cloud to the topology. Right-Click and configure the cloud.
• Under the cloud name -> NIO Ethernet -> Generic Ethernet NIO -> Select the Host Only VirtualBox adapter -> Add -> Apply
• Make a Fast Ethernet connection from the router to the cloud.

You should now be able to configure your router as 172.16.1.1/24 and add the server into the topology. I will be posting a demonstration for authentication for login and PPPoE soon.

Release your old code please

Recently, Microsoft has stopped supporting Windows XP. This is not a surprise. They said they were going to, and its old. I believe in their right to stop releasing security patches but a problem exists. XP is still out there. It is out there for a lot of reasons, to support old hardware, to support old software, or the cost to change for individuals or organizations is just too high right now. And now, XP has vulnerabilities that are never going to be patched, which makes XP an easy target for cyber criminals.

I am a firm believer that the security of the entire Internet affects the security of all networks. There are many reasons for this, think about being a neighbor in your community, if you see someone robbing your neighbor's house, you don't, or shouldn't, think, "Serves him right, he didn't buy the most up to date security system, and locks." No, a good neighbor realizes that the robber is wrong, or at least a smart neighbor realizes with this criminal targeting his neighborhood on the loose, his house may be next.

Another reason to think about how security affects us all is to think about how much organizations spend on the security of their information systems, when all it takes is for an employee to take that information home to work on and have it compromised on his old XP machine.

I do not intend to pick on just XP or Microsoft, there are numerous products out there that are on networks, connected to the Internet or isolated that are no longer supported and no longer getting security updates. The number of such outdated products are just going to grow as we connect more and more systems to the network. One example I could think of would be a network enabled electrical control system for your home. Do you pay for a completely new system once the manufacturer stops making firmware updates?

So, we are all affected and that the easier it is to make a living as a cyber criminal, just like the non-cyber equivalent, the more likely everyone is to become victim to more crimes and more sophisticated criminal organizations will emerge.

I recently read an article, which I unfortunately lost, that suggested organizations release their source code when they stop making security patches. I agree. 100%. The clear advantage being that the open source community will be able to patch vulnerabilities, or another company will make money off of selling patches. It may also allow companies to upgrade hardware while they save money to implement an updated software system that depends on an older OS or other dependency.

The companies selling those products, however, will not like this. Many release only small upgrades between versions and are reusing the majority of their code, this may mean it will take longer for new versions of products to come out. For those type of companies, they should really extend support to the older system if there are only nominal differences in source code. Others may have functions, or routines that they consider critical to the way the products that they sell, such as voice recognition software. I would suggest they either obtain a patent for those methods or partially support updates for those key portions of the application.

I do not believe that it would stifle innovation. Even in the open source world, products are not supported forever. It would actually encourage companies to make more innovated releases to get their customers to make the jump.

It really comes down to national security, security of its citizens, and national interest that source code of these products become public domain.

IPv6 Finally - Part 1

This summary is not available. Please click here to view the post.

Use VLC to share your desktop in a classroom or for a multicast lab

It's been a few weeks since I've posted so I thought I would post a short set of instructions on how I use VLC to create a video stream of my desktop in my classroom.  I also use this method to run a multicast routing lab.  I use the arrow to show what should be selected next in the GUI, you can read it as "then select." 

First from the Instructor/Source computer.  Open VLC.

1. Choose Media -> Stream
2. Capture Device -> Capture Mode -> Desktop -> Stream (this will start a wizard)
3. @Source -> Next
4. @Destination Setup -> New Destination -> RTP / MPEG Transport Stream -> Add
   Address -> 225.99.99.99 -> Next
5. @Transcoding Options -> Profile ->  Video - H.264 + MP3 -> Next
6. @Option Setup -> Stream all elementary streams -> Stream (If you want your stream used for a multicast routing lab, modify the ttl value, to how many routers it will need to traverse; see ttl value set in the cli.)

From the CLI (linux - This is a single line):

cvlc screen:// :screen-fps=10 --sout '#transcode{vcodec=h264,vb=0,scale=1,acodec=none}:
rtp{dst=225.99.99.99,port=5004,mux=ts,ttl=5}' --sout-all --sout-keep

Now from the Student/Client computer.  Open VLC.

1. Media -> Open Network Stream
2. Network URL -> rtp://@225.99.99.99:5004 -> Play

From CLI (linux):

cvlc rtp://@225.99.99.99:5004

Fedora Shortcut - Create a file called Classroom.desktop placed in /usr/share/applications with the following content:

[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=Classroom Video Stream
Comment=Classroom Video Stream
Exec=/bin/cvlc rtp://@225.99.99.99:5004
Icon=vlc
Terminal=false

Puzzle #2 - Find what is broken - OSPF to EIGRP migration

For this puzzle, the organization will be adding a new Ethernet based circuit in between two sites, site 1 with router R1, and site 2 with R2, to alleviate congestion problems between the two sites.  The original circuit had 3 Mbps in both directions while the new circuit has only 1.5 Mbps.

Because the links are of different sizes and the original link had an issue with congestion the organization has decided to switch from OSPF between R1 and R2 to EIGRP because of the ease of configuration for unequal cost load balancing with the variance command.

The change plan is to configure EIGRP in parallel with OSPF.  Verify unequal cost load balancing and remove OSPF from the routers.  The planned configuration for the routers when both protocols are running is found below:

!R1
hostname R1
!
interface FastEthernet0/0
 description ***3M CIRCUIT TO R2***
 bandwidth 3000
 ip address 192.168.0.1 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet0/1
 description ***1.5M CIRCUIT TO R2***
 bandwidth 1500
 ip address 192.168.0.5 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet1/0
 description ***SERVER SUBNET 192.168.1.0/24***
 ip address 192.168.1.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet2/0
 description ***CLIENT SUBNET 192.168.3.0/25***
 ip address 192.168.3.1 255.255.255.128
 duplex auto
 speed auto
!
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet0/1
 network 192.168.0.0 0.0.255.255 area 0
!
router eigrp 1
 variance 2
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet0/1
 network 192.168.0.0 0.0.255.255

!R2
hostname R2
!
interface FastEthernet0/0
 description ***3M CIRCUIT TO R1***
 bandwidth 3000
 ip address 192.168.0.2 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet0/1
 description ***1.5M CIRCUIT TO R1***
 bandwidth 1500
 ip address 192.168.0.6 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet1/0
 description ***CLIENT SUBNET 192.168.2.0/24***
 ip address 192.168.2.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet2/0
 description ***CLIENT SUBNET 192.168.3.128/25***
 ip address 192.168.3.129 255.255.255.128
 duplex auto
 speed auto
!
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet0/1
 network 192.168.0.0 0.0.255.255 area 0
!
router eigrp 1
 variance 2
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet0/1
 network 192.168.0.0 0.0.255.255

The changes seem to go as planned when both protocols are running.  The network administrator performs the "show ip route" command and sees EIGRP routes with unequal cost and performs a traceroute to verify load balancing.

R2#sho ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     192.168.0.0/30 is subnetted, 2 subnets
C       192.168.0.0 is directly connected, FastEthernet0/0
C       192.168.0.4 is directly connected, FastEthernet0/1
D    192.168.1.0/24 [90/1734656] via 192.168.0.5, 00:35:30, FastEthernet0/1
                    [90/881408] via 192.168.0.1, 00:35:30, FastEthernet0/0
C    192.168.2.0/24 is directly connected, FastEthernet1/0
     192.168.3.0/24 is variably subnetted, 3 subnets, 2 masks
O       192.168.3.0/25 [110/34] via 192.168.0.1, 00:17:01, FastEthernet0/0
D       192.168.3.0/24 is a summary, 00:17:03, Null0
C       192.168.3.128/25 is directly connected, FastEthernet2/0
R2#traceroute 192.168.1.1

Type escape sequence to abort.
Tracing the route to 192.168.1.1

  1 192.168.0.1 44 msec
    192.168.0.5 48 msec *
R2#

But shortly after removing OSPF with "no router ospf 1," calls start coming in from site 2 with clients that cannot reach the server subnet.  What happened?  What did the administrator miss before removing OSPF?

10 Good Network Administration Habits That Can Help You Run a More Reliable Network

There are all types of networks with different types of redundancy and connections and all types of environments with all levels of skills and change management processes, but the uptime of the network will often be dependent on the diligence of the network administrator.  This list outlines good habits that prevent common pitfalls.  Although this one is geared towards Cisco, it is true across many platforms.

1. Train your eyes for mistakes.

I’ve seen networks down for not just hours but days because one part of the configuration has a mistyped IP address in the second or third octet and it just keeps getting looked over.  Read the entire IP address; memorize valid masks and their corresponding wildcard masks. 

2. If you redistribute, filter.

Route redistribution will kick you in the teeth if you do it carelessly.  Redistribute only when it is the right solution for the job.  Use a distribution list, prefix list, or route map to obtain the specific results you want. 

You should be even more careful with two-way route redistribution, look into using tags to tag the routes you’ve already redistributed to make sure you are not bringing them back into the process again. 

3. Improve your test plan.

Making a network change and then pinging a couple of interfaces may be a typical test plan in many environments but it doesn’t mean too much if your customers come in the next day and their systems can’t get across the network. Test your change by running or having a customer run critical systems after the change.

4. Turn on logging for any critical process and interface.

Enabling log-neighbor-changes on your routing processes, logging event link-status on important interfaces, setting the logging level to informational, expanding the logging buffer, and sending logs to one or more syslog servers will allow you to get key incite to a network outage.  It’s better to be told what is wrong then for fishing around for clues later.

5. Be vigilant; look for errors, and if you don’t know why something is in your configs, research.

Take a little time in a device if you haven’t logged into it in a while, or schedule some time to go through and review each device.  Check for interface errors and queue drops.  Look for configuration items that look wrong, out of place, or you are unfamiliar with and find out why they are there or if they are supposed to be there.  Identify parts of the configuration that should have been removed during a previous maintenance.

6. Dump the ‘do’ command mentality.

I have a real love-hate relationship with the "do" command.  While it may be convenient at times to make sure things are progressing as expected, it drives me absolutely bonkers when I am assisting other network administrators who log in and go straight into global configuration mode.  Be sure to separate all of your work in to the stages of planning, implementation, and verification; and you’ll find you get much better results.

7. Get another pair of eyes on your implementation plan.

Have an implementation plan that is very detailed, so you can basically paste in the changes you need to make and let someone else perform a serious review.  Many environments have a peer review process or a Change Advisory Board that is supposed to do this, but all too often something slips through the cracks.  The other benefit behind a detailed implementation plan is that your time implementing is significantly reduced. 

8. Take your duplex seriously.

Auto-duplex could be the biggest gremlin in the history of networking.  Vendors have not been so careful in their implementation of 802.3u and there is no such thing as a Fast Ethernet compliancy testing body like there is for WIFI.  There have been documented cases of auto-duplex working fine for years and then it just stops and you have an awful duplex mismatch problem on your hands.  Because of the manufacturer’s lack of diligence, that means it falls on you.  Never take your duplex settings lightly, it is a serious network change.  Even when both sides negotiate full-duplex, switching from auto to full-duplex can bring the link down as it can also disable MDIX when MDIX was making up for your lack of a cross-over cable.

9. Include other sections in your plans.

Let your server administrators and desktop support in on your plans.  They will have input on how it will affect them and take their input seriously.  If you have a separate engineering and administration section, check with the administrators who will end up maintaining the design you come up with and get their input on the old design; you’ll have a better product.

10. Practice gathering all the information you can without "show run."

The novice knows to look at their configuration for errors.  This really only lets you verify the commands you think are there, are actually there.   The expert, however, is familiar with the cornucopia of show commands and (use with caution) debug commands out there to tell you the specific problem or verify your implementation.