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 Userephone-dn 1 dual-linenumber 7890 secondary 1234567890 no-reg bothlabel Johndescription 123-456-7890name John Doecall-forward busy 1000call-forward noan 1000 timeout 20
CUE config for Userusername John create
username John phonenumber “7890”
voicemail mailbox owner “John” size 1772description “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.
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:
- Configure a DHCP Pool for all IP Phones.
- Copy tftp files for the SPA508G phones to flash.
- Configured UC560 to serve up the files so that the phones are able to download their configuration.
- Basic ephone-dn and ephone configurations to test phones.
- Create and assign IP to loopback interface.
- Configure Service-Engine interface to use loopback interface
- Configure IP address and default-gateway of CUE
- Test connectivity to CUE by pinging interface and also establishing connection.
- Configure user accounts in CUE and assign Voicemail mailboxes to users.
- 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. 🙂
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.
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.
R1#sh run | s router bgp router bgp 100 no synchronization bgp log-neighbor-changes network 18.104.22.168 mask 255.255.255.255 network 22.214.171.124 mask 255.255.255.255 network 126.96.36.199 mask 255.255.255.255 network 188.8.131.52 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 *> 184.108.40.206/32 192.168.1.1 0 0 100 i *> 220.127.116.11/32 192.168.1.1 0 0 100 i *> 18.104.22.168/32 192.168.1.1 0 0 100 i *> 22.214.171.124/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 *>i126.96.36.199/32 192.168.1.1 0 100 0 100 i *>i188.8.131.52/32 192.168.1.1 0 100 0 100 i *>i184.108.40.206/32 192.168.1.1 0 100 0 100 i *>i220.127.116.11/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 *>i18.104.22.168/32 192.168.1.1 0 100 0 100 i *>i22.214.171.124/32 192.168.1.1 0 100 0 100 i *>i126.96.36.199/32 192.168.1.1 0 100 0 100 i *>i188.8.131.52/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 184.108.40.206 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 220.127.116.11, 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 *> 18.104.22.168/32 192.168.1.1 0 100 0 (6500) 100 i *> 22.214.171.124/32 192.168.1.1 0 100 0 (6500) 100 i *> 126.96.36.199/32 192.168.1.1 0 100 0 (6500) 100 i *> 188.8.131.52/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.
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.
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.
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.”
Configure a hostname for the router using these commands.
Enter configuration commands, one per line. End with CNTL/Z.
yourname (config)#hostname LabRouter
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
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.
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)#transport input ssh
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
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
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
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.
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.
- 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
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.
Next we configure a host name with the following commands:
Enter configuration commands, one per line. End with CNTL/Z.
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
Then we enable the AAA new-model, specify the RADIUS server and a group to be used.
Cisco871(config)#aaa authentication login CISCO group radius local
Specify which interface RADIUS will be accepting connections on.
Cisco871(config)#ip radius source-interface FastEthernet 4
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
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.