Archive

Archive for the ‘Cisco’ Category

No Voicemailbox association on CUE

January 17, 2013 2 comments

I’ve recently encountered an issue on CUE as it pertains to user mailboxes. Whenever someone tried to leave a message for a particular user, they were told by the AutoAttendant that there was no mailbox associated with the user’s extension. Before we go any further, let’s get some more information on how the environment is currently setup.

CME is configured to use SIP Trunking  back to the ISP in order to make calls. Each user has Direct Inward Dial (DID) extensions. Here’s a sample config of what the Ephone-DN on CME and the Voicemailbox on CUE looks like.

CME Ephone-DN config for User
ephone-dn 1 dual-line
  number 7890 secondary 1234567890 no-reg both
  label John
  description 123-456-7890
  name John Doe
  call-forward busy 1000
  call-forward noan 1000 timeout 20
CUE config for User
username John create


username John phonenumber “7890”


voicemail mailbox owner “John” size 1772
description “John mailbox”
end mailbox


voicemail notification owner John enable

Reviewing the configuration above you would think that your voicemail mailbox configuration for this user is correct, right? Wrong! If you placed a call to this user from an internal phone to their primary extension of 1234, you’d be able to leave a message however, if an external user placed a call to the DID number of 1234567890, they would be told that there is no mailbox associated with the number. The reason for this, is that when an external user places a call to the DID number, the AutoAttendant forwards the entire DID number and tries to find a mailbox associated with this number. Because the primary number associated with the mailbox is 7890 and not 1234567890, the mailbox lookup fails. To correct this issue we would need to change the phone number associated with the mailbox in CUE to the DID number of 1234567890.

username John phonenumber “1234567890”

I was able to verify this by enabling call forwarding to voicemail on the user’s phone, enabling the “debug voice dialpeer” command and then placing a call to that user’s DID number.

Advertisements
Categories: Cisco Tags: , , , , ,

Cisco Unity Express and Loopback0

August 9, 2011 7 comments

I’m currently working on a VOIP project consisting of a pair of UC560s and some SPA508G Phones. Configuration for the project is pretty straight forward as no  fancy or complex translation rules need to be created. The client is basically replacing their current antique Nortel system with a modern Cisco solution.

The steps required for me to get the system up to a basic state to perform tests were as follows:

  1. Configure a DHCP Pool for all IP Phones.
  2. Copy tftp files for the SPA508G phones to flash.
  3. Configured UC560 to serve up the files so that the phones are able to download their configuration.
  4. Basic ephone-dn and ephone configurations to test phones.
  5. Create and assign IP to loopback interface.
  6. Configure Service-Engine interface to use loopback interface
  7. Configure IP address and default-gateway of CUE
  8. Test connectivity to CUE by pinging interface and also establishing connection.
  9. Configure user accounts in CUE and assign Voicemail mailboxes to users.
  10. Perform Tests.

As you can see from the list, this truly is a simple deploy.

All configurations were proceeding just fine until I arrived at step 8. At this stage I should be able to both establish a connection to CUE and also receive replies from pings. However this wasn’t so. For some reason all my ping tests were failing. I checked, rechecked, checked again, then checked again to make sure my configs were correct.

Here’s an example of what the configuration would look like.

!Loopback interface created to use with our Service Engine interface. 
(Cisco's recommended way of configuring it)

interface Loopback0
ip address 192.168.1.1 255.255.255.0

!Service Engine interface used to communicate with the Cisco Unity Express.

interface Integrated-Service-Engine0/0
 description Loopback interface used to manage integrated application module
 ip unnumbered Loopback0
 service-module ip address 192.168.1.2 255.255.255.0
 service-module ip default-gateway 192.168.1.1

Did I miss anything? From the configuration we see that the IP Address of the CUE is 192.168.1.2 and the IP address used to communicate with the CUE is 192.168.1.1 which is the IP of the Loopback interface.

For reasons unknowing to me, this configuration was not working. I was able to successfully establish a session to the CUE, logged in using the same credentials used to login to the UC560 and I was able to proceed with further configurations tasks. I was able to create user accounts, assign them mailboxes, assign Voicemail number so that the application is activated whenever that number is dialed etc. Unfortunately ping tests were still failing and as such when I made a test call to Voicemail, it did not work. There is one step I forgot to include in the list above, and that was to create a dial-peer so that whenever users dialed the Voicemail number it would use that particular dial-peer to transfer the call to the correct destination thereby activating the Voicemail system. This was also completed and the configuration for this can be seen below.

dial-peer voice 2 voip
destination-pattern 600
session protocol sipv2
session target ipv4:192.168.1.2
dtmf-relay sip-notify
codec g711ulaw
no vad

I spent hours researching Cisco’s documentation and reading through different forums. Eventually I saw a user on IPexpert’s OSL was having the same issue. He was able to access and ping CUE whenever he used a physical interface or a SVI as opposed to using a Loopback interface. I decided to test this out for myself by using an SVI, Vlan1 and changed the configuration on the Service Engine to use Vlan1 instead of Loopback0. Of course this worked flawlessly! I was able to ping the CUE IP which enabled me to proceed with my further configuration and testing.

I found the whole thing really interesting, as no where on Cisco’s site mentioned there being instances where the Loopback interface wouldn’t work. Have any of you VOICE folks out there experienced this problem before? Did I miss something with my configs? And please don’t tell me that I needed to reboot/reload/reset CUE as I did this so many times till at one point I had to do a complete factory reset to get basic communication again. 🙂

First encounter with IP Fragmentation and MTU problems

About a week ago, I was called to  a client to investigate issues they were having as it pertains to browsing the internet. To my surprise when I arrived on site and tested the sites they were having issues with, I was able to browse these sites just fine. At first I was told that there were only 2 users having the problem so I decided to check these two laptops to ascertain whether there was some virus on the system that was causing the problem. This of course proved to not be the case, as both laptops were fully protected and virus definitions were up to date. I did some further investigations on the systems, only to discover that all users on the network were experiencing the problem. This puzzled me even more. To prove whether is was a problem with the internet connection, one of the users informed me that he had connected to a near by wifi connection and was able to browse these same sites just fine. This meant that the problem had to lie within the network.

Upon doing some initial research off site on what possible causes for the problem could be, I was advised that it could be a problem with MTU. Given that I never experienced this issue before, I had to dig deeper to get further details. The customer was using Cisco equipment for their switching infrastructure and Juniper for their firewall. I proceeded to take a ASA 5505 on my next visit to the client and swapped out the juniper to test. The tests were successful. All users were able to browse the websites they were having issues with. At this stage I figured we must have had a defective Junos box on our hands so I swapped it out for a replacement that was already on site. Alright, so now we’ve got a brand new spare Juniper SRX in to replace the old one. All should be fine now, right? Wrong! Users began to experience the same issue again. This of course boggled my mind even further. I mean, the internet worked fine with the ASA. I swapped out the old Junos for a replacement, and we’re back with the same problem? What could be the cause?

Back at the office, I was digging deeper, trying to learn as much as I can about the symptoms that can arise whenever you experience MTU issues. Cisco had a great article about this, which totally went in depth  about the causes and possible solutions to the problem. If you’d like to read it for  yourself, you can have a look here. I am by no means familiar with Juniper configurations and the Junos box was managed by another team in Holland. Given how technology works, and how all vendors have basically their own way of achieving the same results, I knew that Juniper must have had an option similar to Cisco’s “ip tcp adjust-mss” command and after some research, I came across this Knowlege Base article about how to achieve the same result in Junos. Working along with the team in Holland, I instructed them of the changes to make and also provided the link to the KB. Users were able to browse all sites just fine once again after the changes were made to the Junos box.

For those of you who are wondering how I was able to browse just fine on the network before the Junos box was configured  and other users weren’t; my laptop had the Cisco VPN Client software installed. This application usually reduces your MTU to 1300. By default Windows uses a MTU of 1500, so if somewhere along the path to the destination, a device was configured for a smaller mtu you could experience the problems as mentioned above.

BGP Route Reflectors and Confederations

June 18, 2011 7 comments

The Border gateway protocol (BGP) is used to exchange network layer reachability information (NLRI) between Autonomous Systems. Like most routing protocols, BGP also has methods of preventing routing loops within networks. iBGP in particular uses the Split Horizon rule to prevent routing loops. The iBGP Split Horizon rule basically states that an iBGP router will not forward any prefixes learned via iBGP to other iBGP speakers because it assumes a full mesh topology. This means that if you have four routers, R1, R2, R3, R4 connected in a daisy chain. R1 being in AS 100 and R2, R3, R4 being in AS 200, any routes learned by R2 via its eBGP peering to R1 wouldn’t be advertised to R4.

To combat this problem, BGP uses two technologies with the goal of allowing your iBGP routers to still receive all routing updates and not require a full mesh topology.

  • BGP Route-Reflectors
    • Route-reflectors allow iBGP speakers to have a partial mesh topology while still propagating all iBGP learned routes to all iBGP speakers
    • Route-reflectors consist of route-reflector servers and route-reflector clients
    • eBGP routes learned by route-reflector servers are advertised to other eBGP neighbors, route-reflector clients and non-clients.
    • iBGP routes learned from non-clients are advertised to eBGP neighbors and route-reflector clients
    • iBGP routes learned from route-reflector clients are advertised to other clients, non-clients and eBGP neighbors.
  • BGP Confederation
    • Confederations achieve the same goal as Route-reflectors
    • This is done by dividing the main AS into several smaller sub-autonomous systems.
    • Typically  the private range used for these sub ASs are in the range 6451-65535
    • Neighbors in each sub-as must still be fully meshed
    • Confederation iBGP/eBGP peers act the same way as BGP iBGP/eBGP peers.

Let’s first take a look at how we would configure route-reflectors followed by confederations. We’ll be using the topology consisting of 4 routers, R1-R4 as shown below.



Base Configuration for R1

R1#sh run | s router bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 network 2.2.2.2 mask 255.255.255.255
 network 3.3.3.3 mask 255.255.255.255
 network 4.4.4.4 mask 255.255.255.255
 network 192.168.1.0
 neighbor 192.168.1.2 remote-as 200
 no auto-summary

Base Configuration for R2

R2#sh run | s router bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
network 192.168.1.0
network 192.168.2.0
neighbor 192.168.1.1 remote-as 100
neighbor 192.168.2.3 remote-as 200
no auto-summary

Base Configuration for R3

R3#sh run | s router bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
network 192.168.2.0
network 192.168.3.0
neighbor 192.168.2.2 remote-as 200
neighbor 192.168.3.4 remote-as 200
no auto-summary

Base Configuration for R4

R4#sh run | s router bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
network 192.168.3.0
neighbor 192.168.3.3 remote-as 200
no auto-summary


Now let’s take a look at the output of the “show ip bpg” command.

Notice that R2 has learned about the loopbacks that are configured on R1 via it’s eBGP relationship with R1.

R2#sh ip bgp

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       192.168.1.1              0             0 100 i
*> 2.2.2.2/32       192.168.1.1              0             0 100 i
*> 3.3.3.3/32       192.168.1.1              0             0 100 i
*> 4.4.4.4/32       192.168.1.1              0             0 100 i
*  192.168.1.0      192.168.1.1              0             0 100 i
*>                  0.0.0.0                  0         32768 i
* i192.168.2.0      192.168.2.3              0    100      0 i
*>                  0.0.0.0                  0         32768 i
*>i192.168.3.0      192.168.2.3              0    100      0 i

Notice R3 also learns of R1’s loopbacks but this time via iBGP as indicated by the “i” in front of the networks.

R3#sh ip bgp

   Network          Next Hop            Metric LocPrf Weight Path
*>i1.1.1.1/32       192.168.1.1              0    100      0 100 i
*>i2.2.2.2/32       192.168.1.1              0    100      0 100 i
*>i3.3.3.3/32       192.168.1.1              0    100      0 100 i
*>i4.4.4.4/32       192.168.1.1              0    100      0 100 i
*>i192.168.1.0      192.168.2.2              0    100      0 i
* i192.168.2.0      192.168.2.2              0    100      0 i
*>                  0.0.0.0                  0         32768 i
* i192.168.3.0      192.168.3.4              0    100      0 i
*>                  0.0.0.0                  0         32768 i

Here on R4 we see the iBGP split horizon rule in effect.

R4#sh ip bgp

   Network          Next Hop            Metric LocPrf Weight Path
*>i192.168.2.0      192.168.3.3              0    100      0 i
* i192.168.3.0      192.168.3.3              0    100      0 i
*>                  0.0.0.0                  0         32768 i

R4 doesn’t learn of R1’s loopback interfaces because R3 isn’t passing the routes on. To correct this problem we’re going to use the first solution available to us, by making R3 a route-reflector server and R4 a route-reflector client. This will then allow R3 to advertise R1’s loopback interfaces to R4. The configuration to make all this happen only needs to be configured on the route-reflector server which is R3 in this case.

Route-reflector configuration for R3

R3(config)#router bgp 200
R3(config-router)#neighbor 192.168.3.4 route-reflector-client

Now let’s take another look at the output of the “show ip bgp” command on R4 to see if it did indeed learn those routes.

R4#sh ip bgp 

   Network          Next Hop            Metric LocPrf Weight Path
*>i1.1.1.1/32       192.168.1.1              0    100      0 100 i
*>i2.2.2.2/32       192.168.1.1              0    100      0 100 i
*>i3.3.3.3/32       192.168.1.1              0    100      0 100 i
*>i4.4.4.4/32       192.168.1.1              0    100      0 100 i
*>i192.168.1.0      192.168.2.2              0    100      0 i
*>i192.168.2.0      192.168.3.3              0    100      0 i
* i192.168.3.0      192.168.3.3              0    100      0 i
*>                  0.0.0.0                  0         32768 i
R4#
R4#ping 4.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

Success!!! We see that R4 is indeed now learning the routes via it’s iBGP neighbor R3 and we also have reachability.

Moving onto BGP Confederations. For this example we’re going to use the same topology however we’re going to sub-divide AS200 into As6500 and AS6501

One thing to note about Confederation configurations is that we first create the sub AS and then identify what our actual AS is within BGP sub configuration mode. I personally don’ t know why Cisco decided to implement Confederations in this way but this wouldn’t be the first time we’ve all scratched our heads at how Cisco chooses to implement stuff. Configurations for R1 will remain exactly the same, however for all other routers in AS200 (Confed AS 6500 and AD6501), we’re going to have to first remove the “router bgp 200” configs then proceed with the configurations. R2 and R3 are going to be placed into sub AS 6500 while R4 will be placed in sub AS6501.

The reason for us placing R4 into a separate sub AS to R2 and R3 is because Confederation iBGP/eBGP peers act exactly the same way as iBGP/eBGP peers. This means that a full mesh would still be required for all routers within the same sub AS. Had we placed R4 into the same sub AS as R2 and R3 the split horizon rule would have prevented R3 from advertising the networks on R1, to R4.

Confederations config on R2

R2#sh run | s router bgp
router bgp 6500
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 200
 bgp confederation peers 6501
 network 192.168.1.0
 network 192.168.2.0
 neighbor 192.168.1.1 remote-as 100
 neighbor 192.168.2.3 remote-as 6500
 no auto-summary

Confederations config on R3

R3#sh run | s router bgp
router bgp 6500
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 200
 bgp confederation peers 6501
 network 192.168.2.0
 network 192.168.3.0
 neighbor 192.168.2.2 remote-as 6500
 neighbor 192.168.3.4 remote-as 6501
 no auto-summary

Confederations config on R4

R4#sh run | s router bgp
router bgp 6501
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 200
 bgp confederation peers 6500
 network 192.168.3.0
 neighbor 192.168.3.3 remote-as 6500
 no auto-summary

Output of “show ip bgp” on R4

R4#sh ip bgp 

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       192.168.1.1              0    100      0 (6500) 100 i
*> 2.2.2.2/32       192.168.1.1              0    100      0 (6500) 100 i
*> 3.3.3.3/32       192.168.1.1              0    100      0 (6500) 100 i
*> 4.4.4.4/32       192.168.1.1              0    100      0 (6500) 100 i
*> 192.168.1.0      192.168.2.2              0    100      0 (6500) i
*> 192.168.2.0      192.168.3.3              0    100      0 (6500) i
*  192.168.3.0      192.168.3.3              0    100      0 (6500) i
*>                  0.0.0.0                  0         32768 i

Success!!! R4 learns of R1’s networks via it’s Confederation eBGP relationship with R3. Notice that the networks do not list the “i” in front of them to indicate it as being learnt via iBGP. This shows clearly how similar Confederation eBGP peers and normal eBGP peers are in terms of their neighbor relationships.

As we’ve seen throughout this post, both Route-Reflectors and Confederations can be used to solve the iBGP Split Horizon problem without the need for a full mesh topology within your BGP networks. I personally don’t have any production experience dealing with these technologies but if I had to choose one, I’d go with route-reflector just because the configuration is a lot simpler :-). Also one other advantage that came up during my group  study session with @aconaway was that you would need to plan ahead if you ever wanted to implement Confederations. Reason for this is because the way in which BGP Confederations are configured in IOS. Let’s say we had some eBGP peers early in our network when it was a lot smaller but now your network has grown to a size that requires Confederations. You would need to remove the “router bgp AS” command thereby removing all BGP configurations on that router, then proceed with your Confederation configs where as with route-reflectors you simply need to place the “neighbor x.x.x.x route-reflector-client” command to achieve the same result.

Disclaimer

This post was mainly written to aid me with my studies. The views expressed are based on my understanding and research of the technologies. Because this is a learning process mistakes may be committed to which I would greatly appreciate it if you would point those out via the comments section.

Why and how to configure Secure Shell (SSH) on a Cisco router

January 17, 2010 Leave a comment

This was taken from one of my posts I did for TrainSignal. From time to time you’ll see me post articles here that I wrote for TraingSignal.

Security continues to dominate the IT industry and is one of the most important factors to consider when designing and deploying networks. It is, therefore, imperative that we are able to ascertain and prevent most, if not all, vulnerabilities that may exist. One such weakness is Telnet to which SSH is the alternative. We will be taking a deeper look at how you would enable and configure your Cisco Router to use SSH and why we should always use SSH where possible as opposed to using Telnet.

We all know that when it comes to security within the networking universe, Cisco is one of the biggest players. However, just having a Cisco device doesn’t mean that you are secured. The onus is on you to ensure that you’ve configured that device properly to prevent most, if not all, loopholes.

Secure Shell (SSH)

Secure Shell (SSH) improves network security by providing a means of establishing secure connections to networking devices for management, thereby preventing hackers gaining access. Using Digital Certificates, in a Public/Private Key Cryptography,
SSH is able to authenticate clients or servers, thereby ensuring that the device or server you are about to connect to is exactly who they claim to be.

Ok, so now that we have a very brief idea of how SSH secures network traffic, the next step is figuring out where to get this thing we call a digital certificate. Do we have to go into a store to purchase it? Digital Certificates can be acquired in generally three different ways. The most secure (and expensive), requesting it from a trusted company called a CA – Certificate Authorities. An example of one such company is VeriSign, which is highly popular within the CA Industry for their role in providing worldwide trusted certificates; these certificates can cost quite a bit. There are two other ways of requesting a certificate. One is by using an internally trusted CA (trusted within a company) also called an enterprise CA or by generating a self sign certificate on the device itself. The last one is the lease secure form but provides more than enough security to lock down your average network device. This self signed certificate can be generated using the built in commands on your Cisco router.

Like SSH, Telnet can also be used to connect to your router but, the main disadvantage of using Telnet is that it does not encrypt its connections. This means that if a hacker is able to capture packets from a Telnet session, he or she would be able to view information contained within those packets, such as a client’s username and password, and can, therefore, gain access to your router. The diagram below will give you an idea of how this works.

Router Configuration

Now that we’ve gotten an understanding of how SSH works and why we should use SSH as opposed to using Telnet, the next step is actually getting down to configuring the device, which is always my favorite part.

For this exercise I will be using a Cisco 871 series SOHO router with IOS ver. 12.4 software. Depending on whether your router is brand new or currently in a production environment, you’re going to have to either connect via a Console session or through a Telnet session. Have a look at my article on “Configuring a Cisco router to use RADIUS for authentication –
INSERT LINK http://www.trainsignaltraining.com/using-radius-for-authentication/2009-08-20″ for the steps needed to connect via a Console session or you can check this article on Cisco’s website “INSERT LINK http://www-tss.cisco.com/eservice/compass/common/tasks/task_console_port_connect.htm.”

  1. Configure a hostname for the router using these commands.

     

    yourname#configure terminal
    Enter configuration commands, one per line. End with CNTL/Z.

    yourname (config)#hostname LabRouter

    LabRouter(config)#

 

  1. Configure a domain name with the ip domain-name command followed by whatever you would like your domain name to be. I used CiscoLab.com.

     

    LabRouter(config)#ip domain-name CiscoLab.com

 

  1. We generate a certificate that will be used to encrypt the SSH packets using the crypto key generate rsa command. Take note of the message that is displayed right after we enter this command. “The name for the keys will be: LabRouter.CiscoLab.com”. It combines the hostname of the router along with the domain name we configured to get the name of the encryption key generated; this is why it was important for us to, first of all, configure a hostname then a domain name before we generated the keys. Notice also that it asks us to choose a size of modulus for the key we’re about to generate. The higher the modulus, the stronger the encryption of the key. For our example, we’ll use a modulus of 1024.

     

 

  1. Now that we’ve generated the key, our next step would be to configure our vty lines for SSH access and specify which database we are going to use to provide authentication to the device. The local database on the router will do just fine for this example.

     

    LabRouter(config)#line vty 0 4

    LabRouter(config-line)#login local

    LabRouter(config-line)#transport input ssh

  2. You will need to create an account on the local router’s database to be used for authenticating to the device. This can be accomplished with these commands.

     

    LabRouter(config)#username XXXX privilege 15
    secret XXXX

 

Fine Tuning your Configuration.

We’ve pretty much completed all the steps needed to configure and use SSH on your router; however, there are some other configurations that can be made to further secure your device. For one, I would highly recommend you enabling an exec time-out on your router to prevent anyone from gaining access to the device in cases where you forgot to logout or got distracted because of an emergency. This way, the router will automatically log you out after the session has been idle for a set time. You must configure this command on the line interface as depicted below.

LabRouter(config)#line vty 0 4

LabRouter(config-line)#
exec-timeout 5

 

This means that if the session has been idle for 5 minutes, the router will automatically disconnect the session.

 

Use Access Control Lists (ACL) as an added layer of security; this will ensure that only devices with certain IP address are able to connect to the router. Let’s say the IP Subnet for your LAN is 192.168.100.0/24, you would create an acl to permit only traffic from that subnet and apply this acl to the vty lines.

LabRouter(config)#access-list 1 permit 192.168.100.0 0.0.0.255

LabRouter(config)#line vty 0 4

LabRouter(config-line)#access-class 1 in

 

Another crucial point to note is the use of SSH2 as opposed to using SSH1. SSH2 improves on a lot of the weaknesses that existed within SSH1 and for this reason I recommend always using SSH2 where possible. Enable SSH version 2 with this command:

LabRouter(config)#line vty 0 4

LabRouter(config)#ip ssh versopn 2

 

Detailed reading on SSH can be done at RFC 4251 “INSERT LINK
http://www.ietf.org/rfc/rfc4251.txt

Categories: Cisco Tags: , , ,

Configure a Cisco router to use RADIUS for authentication

January 16, 2010 Leave a comment

Abstract: Networks usually consist of a wide range of devices from different vendors that require some means of authenticating users before they are granted access to resources. With that comes the added administrative burden of having to manage all the different accounts on each device; Remote Authentication Dial In User Service (RADIUS), is one means of countering this issue by providing a centralized infrastructure for authentication and accounting.

Now there are a lot of technical papers on configuring devices for RADIUS but I’m going to be doing things a little different in this article; I’m going to be giving you a brief overview of RADIUS, how it operates and how to incorporate it into any Cisco routers that you may have in your network.

What is RADIUS?

RADIUS is a widely implemented networking protocol sometimes referred to as a client/server protocol, which provides a centralize mechanism of administering Users Account information. These can be usernames, passwords and privilege level for each account. AAA which stands for Authentication, Authorization and Accounting, are the core foundations upon which RADIUS is built. Authentication is the process by which the RADIUS server verifies the user requesting access before it is granted whereas Authorization deals more with the level of access granted to a particular account. The Accounting aspect logs user’s session, thereby allowing an administrator to ascertain the length of time a specific account may be using the resource for and also to perform other administrative tasks.

Before a device can become a RADIUS client it first must be configured with the same pre-shared key as is configured on the RADIUS server thus allowing it to be able to pass user credentials onto the RADIUS server for verification.

When a user needs to access resources, they are required to provide credentials so as to verify that they have the required privileges to get that level of access to the given resource; this may be access to a Router, Switch, Access Point, Firewall or just data on a File Server.

These credentials are passed to a RADIUS client who then forwards it to the RADIUS server. The RADIUS server queries the credentials against its database before a result of access-accept or access-reject is sent back to the RADIUS client. Note for our example the RADIUS client will be a Cisco800 series router, specifically a Cisco 871; the database will be Active Directory configured and running on a Windows Server 2008 box; This article is focused on the configuration of the Cisco router.

Figure 1

Showing the Authentication process when the user tries to access the router

Configure the Cisco 871

As a Cisco administrator you should already know the very basics at least of setting up your device but for those of you that have never configured one before, I’m going to go through these basic steps thus allowing even a novice to get any Cisco router configured to use RADIUS.

To connect to your Cisco Device you will need a terminal program such as HyperTerminal that comes with Windows XP or if you’re using Windows Vista like me then you’ll need a third party software; I like PUTTY so I’ll be using this throughout the lab.

  1. First we need to configure the terminal software with the correct Serial settings as listed below after which we would begin the session by clicking open.

 

  • Bits per sec : 9600
  • Data bits : 8
  • Parity : none
  • Stop bits : 1
  • Flow control : none

 

Figure 2

  1. After you have clicked open, you will be prompted to enter the credentials to gain access to the device. These credentials would be what you have configured before on the router or if it’s a brand new router you will have to use Cisco’s default credentials for that particular model. As was stated before the model of router I’m using is a Cisco 871 series and the default credentials for that are cisco, cisco for the username and password respectively.

     

  2. Next we configure a host name with the following commands:

     

    Router#configure terminal

    Enter configuration commands, one per line. End with CNTL/Z.

    Router(config)#hostname Cisco871

  3. Depending on the role your router is going to play in your network your interfaces will be configured accordingly. For this example I already have a fully operational network therefore I only need to configure the WAN interface to receive an IP address and enable the telnet interface so that I can access the router from any pc or laptop as opposed to using the direct serial connection.

     

    Cisco871(config)# interface fastethernet 4

    Cisco871(config-if)#ip address dhcp

    Cisco871(config-if)#noshutdown

  4. Then we enable the AAA new-model, specify the RADIUS server and a group to be used.

     

    Cisco871(config)#aaa new-model

    Cisco871(config)#aaa authentication login CISCO group radius local

  5. Specify which interface RADIUS will be accepting connections on.

     

    Cisco871(config)#ip radius source-interface FastEthernet 4

  6. Continuing along, we’re going to add the RADIUS server and the key noting that the key used would be the same key that was configured on the RADIUS server.

     

    Cisco871(config)#radius-server host xxx.xxx.xxx.xxx

    Cisco871(config)#radius-server key xxxx

  7. Our last step is to configure the same RADIUS group (CISCO) we defined earlier under the vty lines as the authentication method to be used.

     

    Cisco871(config)#line vty 0 4

    Cisco871(config)# login authentication CISCO

    Cisco871(config)#transport input telnet

 

At this stage we should be able to use telnet to connect to the router and provide the credentials of a user in our Active Directory database with the required “dial in” access.

Further reading on RADIUS can be done in article RFC 2865 of The Internet Engineering Task Force (IETF) website.

Categories: Cisco Tags: , , ,