It’s a weird feeling leaving a job, especially one where you have made so many changes. There is only a small network here (~700 users, ~200 servers) but when I started it had been badly neglected for several years – There wasn’t really anyone with sufficient experience to manage a network, so things had just been left and fingers crossed that nothing would go wrong…

During my time here I have implemented many things that I hope will make the network faster, more stable and more resilient, as well as some procedural changes to help keep things going smoothly when I’m gone. Here is a snippet of some of the things I’ve done during my tenure here;

• Documentation/Diagrams – There were virtually no complete diagram of the network, or accompanying documentation, for maybe the first month of my time here, I was on my hands and knees in computer rooms chasing cables, or sat with a scrap of paper trying to map things out using CDP. Once I had a full diagram of the network, I realized just how bad things were.
• Redundant Links – were non-existence, the whole network was a mess of SPOF’s (Single Point of Failure)   To be fair to the original designers, you could see what they had planned, and in many cases implemented, but due to lack of accurate monitoring, they had one by one failed (GBIC’s/SFP failure, fibres that had been crushed etc…) This leads to….
• Monitoring – there was an installation of Solarwinds NPM, but it was not being fully utilized, only nodes were monitored, and then only by ICMP – no interface status, no SNMP, no traffic graphs etc… I pretty much started from scratch with monitoring. I installed NCM alongside NPM so that there was actually some configuration management as well as monitoring. All the major interfaces were monitored, alerts configured, configurations backed up, even syslog and SNMP traps setup and alerts generated.
• VLAN’s – No one seemed to know how to change the VLAN on a switchport, instead the desktop support guys had a diagram of which switchport’s were configured to which VLAN’s for each switch and just ran a cable, in some instances, this let to cables being stretched across multiple cabs (see my previous posts about recabling the Patching Room) I’ve now gone as far as giving the desktop guys privileges on the access switches to change VLAN’s themselves to speed up desk moves etc…
• Remote Authentication – all the equipment was accessed using local accounts, when someone started or left, you can imagine the trouble going to all the kit and changing it, and forget about regular password changes – so people just didn’t bother, there were accounts on there that were for people who had been left 4/5 years. I used windows NPS (Network Policy Server) as a Radius Server, and went to each device, removed all the local accounts (accept a backup local admin account) and configured them for AAA and Radius. Now people use their domain credentials, which are controlled by the AD Password Policies, and the local admin account has the password changed often (which is very easy to do thanks to NCM!!!)

There are many many other things I have done here to try to bring the network up to scratch, unfortunately there are still many many things that need to be done, but I have been unable to due to the people who sign the cheques being unwilling to spend the money. I can, however, at least say it is in a MUCH better state than when I started.

Before I wrote this post, I decided to have a last walk around the computer rooms and patching rooms and couldn’t help feel a little sad. This was my first job where I had my “own” network, I know every cable and every switch, and I just hope it won’t miss me too much! I believe they are looking for a replacement, as I think they realized they can’t have the situation again where things are left to rot. I just hope the new engineer who comes in looks after it and treats it well…   …anyway, Nexus – here I come!!!

One of the areas I have not really had much exposure too is IPv6.  So I have spent the last few days going over the theory behind it, and trying to put it into practice.

Below is the topology i have been using for MP-BGP (MultiProtocol BGP)

I have used /127 addresses for the links between the routers, and R1 and R3 have loopback interfaces to simulate host networks.

Again, I am new to IPv6 so any feedback on design etc.. is welcome!! I’m assuming that anyone reading this has some experience of BGP in IPv4 networks, so i;m not going into massive depth on the config as mostly its the same, just different

First step is to configure the IPv6 addresses on the interfaces;

R1
interface FastEthernet0/0
 ipv6 address 2001:1::/127

R2
interface FastEthernet0/0
 ipv6 address 2001:1::1/127
interface FastEthernet0/1
 ipv6 address 2001:2::/127

R3
interface FastEthernet0/1
 ipv6 address 2001:2::1/127

Next, enable IPv6 routing globally with the “ipv6 unicast-routing” command. Now to configure the loopback interfaces

R1 user 2001:11:: and R3 uses 2001:10::

interface Loopback0
 ipv6 address 2001:11::1/112
interface Loopback1
 ipv6 address 2001:11::1:1/112
interface Loopback2
 ipv6 address 2001:11::2:1/112
interface Loopback3
 ipv6 address 2001:11::3:1/112
interface Loopback4
 ipv6 address 2001:11::4:1/112

There are several stages to configuring MP-BGP, first is to enable BGP and disable IPv4. Unlike OSPFv3 you configure MP-BGP under the same process as standard BGP

router bgp 1545
 bgp router-id 1.1.1.1
 no bgp default ipv4-unicast

Now, add your peer’s IPv6 address and the remote ASN

 neighbor 2001:1::1 remote-as 8547

You now need to create an IPv6 address family, and add the neighbor to it

 address-family ipv6
  neighbor 2001:1::1 activate

Any other BGP commands you might want to use are carried out within the address-family – network, aggregate-address, additional neighbor commands. So in order to advertise the loopback interfaces;

 address-family ipv6
  network 2001:11::0:1/112
  network 2001:11::1:1/112
  network 2001:11::2:1/112
  network 2001:11::3:1/112
  network 2001:11::4:1/112

and if we want to create a summary range

 address-family ipv6
  aggregate-address 2001:11::/96 summary-only

The full BGP configs for all 3 routers are as follows

R1

router bgp 1545
 bgp router-id 1.1.1.1
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 2001:1::1 remote-as 8547
 !
 address-family ipv6
  neighbor 2001:1::1 activate
  network 2001:11::0:1/112
  network 2001:11::1:1/112
  network 2001:11::2:1/112
  network 2001:11::3:1/112
  network 2001:11::4:1/112
  aggregate-address 2001:11::/96 summary-only
  no synchronization
 exit-address-family

R2

router bgp 8547
 bgp router-id 2.2.2.2
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 2001:1:: remote-as 1545
 neighbor 2001:2::1 remote-as 8547
 !
 address-family ipv6
  neighbor 2001:1:: activate
  neighbor 2001:2::1 activate
  neighbor 2001:2::1 next-hop-self
 exit-address-family

R3

router bgp 8547
 bgp router-id 3.3.3.3
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 2001:2:: remote-as 8547
 !
 address-family ipv6
  neighbor 2001:2:: activate
  neighbor 2001:2:: next-hop-self
network 2001:10::0:1/112
network 2001:10::1:1/112
  network 2001:10::2:1/112
  network 2001:10::3:1/112
  network 2001:10::4:1/112
  aggregate-address 2001:10::/96 summary-only
 exit-address-family

The show commands have also changed slightly, some examples are;

• show ip bgp > show ip bgp ipv6 unicast
• show ip bgp summary > show ip bgp ipv6 unicast summary

Hopefully this is all good, again, i cant stress enough, I’m a novice in terms of IPv6, so please feel free to comment with suggestions and improvements.

But what if something “down the line” fails…

Take this example to the right, R1 and R2 have a HSRP group between them for the 10.0.0.0/24 network, with R1 having the higher priority. R6 is playing the part of “host” and has a default route to the HSRP Virtual IP Address.

The aim of the lab is to ensure that R6 can always get to the 4.2.2.2 address on R5. There is a very basic OSPF setup between R1, R2, R3, R4 & R5, with R5 propagating default information.

What happens if the link between R1 and R3 were to fail, R1 and R2 would be able to speak to each other, so R2 would not take over as the Active HSRP node.

All of a sudden, R6 has lost connectivity to 4.2.2.2

There are a few different tools at our disposal to combat this problem – IP SLA and Tracking.

IP SLA is Internet Protocol Service Level Agreement, and allows you to retrieve statics for all manner of things, from as simple as a ping response, to making sure a TCP Port is open, to path jitter for your IP Telephony deployments.

Tracking allows you to track a wide range of objects, such as interface status, or the results of an IP SLA object.  Tracking objects are either UP or DOWN. Tracking can be used to influence a number of things – HSRP priority, GLBP weighting or policy routing decisions.

In this first example, we are going to be using IP SLA to checking that R1 can ping 4.2.2.2 with a source IP of 10.0.0.11, and then creating a tracking object.

ip sla 10
 icmp-echo 4.2.2.2 source-interface FastEthernet0/1
 frequency 5
ip sla schedule 10 life forever start-time now
!
track 10 rtr 10

You won’t get SLA information unless you add the schedule line (you can set it to only function during certain times etc…)

Once it’s up and running, the below command shows the results

R1#show ip sla statistics 10

R1#show track brief
Track   Object                           Parameter        Value Last Change
10      rtr         10                   state            Up    00:06:28

You can see that the SLA object is getting a response, so returning an OK code, and therefore the tracked object is showing as UP.

Tracked objects do work without SLA objects, the following checks that a certain route exists in the routing table

track 20 ip route 0.0.0.0 0.0.0.0 reachability

When you look at the tracked object, it confirms the state, and even shows you where the route is learned from.

R1#show track 20
Track 20
  IP route 0.0.0.0 0.0.0.0 reachability
  Reachability is Up (OSPF)
    7 changes, last change 01:33:21
  First-hop interface is FastEthernet0/0

You can also use tracking to check the state of interfaces, you can check layer 1/2

track 40 interface FastEthernet0/0 line-protocol

or layer 3

track 30 interface FastEthernet0/0 ip routing

This is a type of tracking object called a list, this lets you bundle several other tracking objects together.

track 1 list boolean and
 object 30
 object 40

Tracking lists are using boolean logic to decide its status, you have a choice of OR or AND

OR – if any object is up, the main track group is up
AND – all objects need to be up for the main track group to be up (if any single object is down, the group is down)

If you have a particularly flaky network; and things might blip very quickly, or you just want to allow a little time to make sure the condition is true before things start failing over, you can add delays to a tracked object, either when they are due to go down, or up.

track 1 list boolean and
 delay down 10 up 10

this means that when trigger changes, and the object should be down, it will wait 10 seconds before actually changing its status, obviously, if the conditions change during this count down, then the countdown will cancel and the object will remain up. Equally, using the up delay, when an object is down, and is due to change to up, it will take 10 seconds before actually changing.

Track 1
  List boolean and
  Boolean AND is Up, delayed Down (8 secs remaining)
    2 changes, last change 00:09:33
    object 30 Down
    object 40 Down
  Delay up 10 secs, down 10 secs

So now you have setup all your tracked objects, what can you actually do with them? with HSRP, you can use the tracked object to adjust the routers priority, in the example above, HSRP is setup between R1 and R2,

R1 priority = 200
R2 priority = 180

In this example, when any of the tracked object are triggered, they will decrement the routers priority by 30, taking its priority to below that of R2, and because preempt is configured, it will cause R2 to transition into Active state.

interface FastEthernet0/1
 ip address 10.0.0.11 255.255.255.0
 standby 10 ip 10.0.0.1
 standby 10 priority 200
 standby 10 preempt
 standby 10 track 10 decrement 30
 standby 10 track 20 decrement 30
 standby 1 0 track 1 decrement 30
end

You can use tracking objects for adjusting the weighing in GLBP

interface FastEthernet0/1
 ip address 10.0.0.12 255.255.255.0
 speed 100
 full-duplex
 glbp 10 ip 10.0.0.1
 glbp 10 priority 200
 glbp 10 preempt
 glbp 10 weighting track 1 decrement 30
 glbp 10 weighting track 30 decrement 30
 glbp 10 weighting track 40 decrement 30

or, you can use it to verify the existence of a next hop in your policy based routing

ip sla 15
 icmp-echo 10.0.0.12
ip sla schedule 15 life forever start-time now
!
track 15 rtr 15
!
route-map MYROUTEMAP permit 10
 set ip next-hop verify-availability 10.0.0.12 1 track 15

We currently have 4 cores (2 at each site) with a full mesh connectivity between them. Each link comprises of 2x 1Gbps fibers bundled together into 2Gbps etherchannels.  There is also layer2 connectivity between cores at each site (allowing cores within a site to be EIGRP neighbors.

Despite the quite redundant looking diagram above, this only provides us redundancy from GBIC/SFP/Line card failures. The fact is that all of these fibers go into 2 multicore fibers running in the same duct underground, so we are still quite vulnerable.

The WIFI Bridge has an AP at both sites, each one connected back to a core.

Once we had confirmed IP connectivity between the two sites via the WIFI bridge, we configured EIGRP to work over the links, the neighbor relationships formed, and BAM utilization on the WIFI link shot to 100%. so i grab a few “show” outputs and disabled EIGRP to return traffic back to normal.

What i discovered was that because we use VLAN’s for alot of routing, the minimum bandwidth EIGRP see’s is usually a gig, the below shows a routing table entry for a subnet that is load sharing over two of the fiber links

D       10.21.10.0/24 [90/3072] via 10.0.0.22, 21:04:21, Port-channel2
                    [90/3072] via 10.0.0.18, 21:04:21, Port-channel3

you can see the minimum bandwidth is always 1000000 Kbit, so its the delay that is used to determine which routes end up in the routing table, as some routes are 2 hops, the delay is incremented per hop, as the below “show ip eigrp topology x.x.x.x” shows;

IP-EIGRP (AS 99): Topology entry for 10.21.10.0/24
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 3072
  Routing Descriptor Blocks:
  10.0.0.22 (Port-channel2), from 10.0.0.22, Send flag is 0×0
      Composite metric is (3072/2816), Route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 20 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  10.0.0.18 (Port-channel3), from 10.0.0.18, Send flag is 0×0
      Composite metric is (3072/2816), Route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 20 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  10.1.1.11 (Vlan1001), from 10.1.1.11, Send flag is 0×0
      Composite metric is (3328/3072), Route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 30 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
  10.0.0.1 (Vlan1000), from 10.0.0.1, Send flag is 0×0
      Composite metric is (3328/3072), Route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 30 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

As the Wireless bridges are connected to Gigabit ports, EIGRP sees the bandwidth as 1000000 Kbit, and the delay as 20microseconds, hence being introduced into the routing table and being seen as an equal cost to the fiber links.

There is a very simple way to correct this issue, and that is to use the interface command “bandwidth” to change the perceived bandwidth of the link (note: only perceived bandwidth, as the link will still transfer packets as fast as it can)

interface Vlan900
 bandwidth 10

Setting the bandwith to 10 means that EIGRP sees the link as only 10k, and therefore pretty much guarantees that it will be the absolute last choice link. The below shows all the available paths to the 10.21.10.0/24 network, Po2 & Po3 are the fiber links, Vlan1000 is the EIGRP VLAN between cores in the same site, and VLAN 900 is used for the WIFI Bridge.

P 10.21.10.0/24, 2 successors, FD is 3072, serno 8990
        via 10.0.0.22 (3072/2816), Port-channel2
        via 10.0.0.18 (3072/2816), Port-channel3
        via 10.0.3.1 (256000512/2816), Vlan900
        via 10.1.1.11 (3328/3072), Vlan1001
        via 10.0.0.1 (3328/3072), Vlan1000

As you can see, the metric is very high, meaning that if variance were to be increased to allow unequal cost load balancing there is still a high probability that this route would not be selected.

  10.0.3.1 (Vlan900), from 10.0.3.1, Send flag is 0×0
      Composite metric is (256000512/2816), Route is Internal
      Vector metric:
        Minimum bandwidth is 10 Kbit
        Total delay is 20 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1

By default the management addresses of the AP’s will be on the native VLAN, however there is an option to enable a management VLAN so that management traffic (HTTP, SNMP, SSH etc…) will be tagged with the appropriate VLAN ID.

Now the big question – Speed.
Despite our initial testing being around 200Mbps, we were only able to get around 110Mbps out of it. The theory is that when we tested it in February time, the trees were not as dense as they are now, and whilst it works through the trees, they do appear to be causing speed issues.

Still, the original line of sight solution was 10Mbps, so for 2 grand we have managed to increase the speed by 10x. As long as we have a fiber failure over winter, we’re laughing!!!

Someone previously had installed a laser Line of Sight system, which delivered about 10Mbps, however what they neglected to realize when it was installed (maybe 6 years ago) was that trees grow. The woodland is green belt so we couldn’t touch the trees, and what use is 10Mbps anyway!! we push around 300Mbps between sites at any one time, going up to 500-600Mbps at peak times.

After looking at several solutions, we approached the company who supplied our corporate WIFI – Evolution Systems – who are a reseller for Ruckus. We use a Ruckus Zonedirector 1000 and a variety of different Ruckus AP’s to provide WIFI services to the offices, warehouse and a Guest SSID. So we were happy to have a look at the Ruckus Site to Site solution.

Evolution suggested we look at the Ruckus 7731 802.11n Bridge . Given the distance, according to the specs should expect to get at least 190Mbps, so this would provide us with sufficient bandwidth as a backup.

The guys from Evolution arranged a proof of concept by putting the AP’s on a temporary pole at each site, connecting each one to a laptop, and checking the speed between them. We were getting around between 170 – 180 Mbps, however they were not as high as they would be when permanently mounted  nor were they fully aligned for best performance. Given the speeds we decided to go ahead with them, and, signed PO in hand, we rang Evolution to place the order.

Today, after what seems like months of getting the necessary risk assessments completed (don’t your love health and safety!!) , the contractors arrived to install the mounting brackets.

Here are a few piccies from the install, we are still waiting to get the data cables run from the mounting brackets to the comms cabinets, once they are in we will be able to get a full speed test completed, fingers crossed for 200Mbps!!  !

(p.s. in the first picture, the ugly square thing is the old Laser Line of Sight)

A few months ago, I was sure that i was going to be going straight on to CCNP R&S. However, since then, I have done 0 studying for it! having a 7 month old baby girl means my time is somewhat limited.

My CCNA expires in January next year (3 years already!??!??!!??) so rather than re-sit I really want to do another certification. My thoughts – CCDA – the syllabus looks pretty easy, it’s mostly common sense from what I’ve heard. I did most of the studying for it about 12 months ago, so I think I just need a bit of a refresher and I should be good to go.

this way i get another 3 years to do at least one of the CCNP modules, which I’m sure I will, maybe SWITCH, I spend 80% of my time dealing with switching issues, so I don’t think it will be too complicated. It’s the ROUTE and TSHOOT that worry me slightly. ROUTE isn’t too bad, but TSHOOT is still a bit of an unknown quantity. Maybe I will have to save my pennies and go on a course rather than the self-study route.

We still have a few little things to troubleshoot – namely some patch panel that got damaged and need to be re-terminated on new panels – awaiting for our cabling contractor to get back to us on that, and I’m heading back in tomorrow to sort out some printers that are on the wrong VLAN etc…

Other than that, it all went very well, all the hours of planing ensured we had minimal issues.

We had a web cam running capturing a picture every 10 seconds, here’s the time-lapse video;

First, here are some pictures to remind you what we were dealing with;

We started by removing all of the old cables, that took around 5 hours, and was one of the most physically demanding jobs of the whole project. After 8 years or so, the network cables had become so tangled, we could only remove them in big clumps (a hacksaw came in useful here!)

There were an awful lot of cables, so one og the guys decided to dive into it

By now we were starting to flag, luckily we had lots of sugar and supplies to keep us going, diabetic Stu was finding it hard to resist the allure of all the sweets!

With all the cables out, we rearranged the cabinet layout, previously all the switches were at the top of the cabs meaning ports at the bottom needed excessively long cables, so we arranges the cabs so the switches are distributed across the height, meaning you never need more than a 1 meter cable, often only 0.5 meter;

The next step was to begin the job of repatching in the data (the green cables)

Next the phone cables (the blue ones) needed to be run in from the phone system opposite the data cabs

Last job, tidy up the fibre in the cabinet containing the upstairs core switch

I have uploaded all of these pictures and more to flickr here

So there you go, we have another comms room that is in nowhere near as bad a state, but will still be a big job non the less. But having only just finished this one, will be a few months yet before we tackle that one

Imagine, if you will, 8 – 10 years of poor cable management, poor cabinet layout, and cables 10x too long for the job at hand. Whatever you now have in your head, double it, and you might be getting close to our upstairs comms room.

This mass of cables to the right is comprised of around 2000 floor ports and 19 1u 18 port switches, and a whole heap of cable! I would say at least 50% of the cable is not actually in use, but has become so tangled and matted, it’s easier for the guys to run a new cable than move the old one – which obviously only serves to compound the problem!!

This single room has around 60% off our office space and 30% of our warehouse space patched into it. So downtime windows long enough to tackle this mess are few and far between.

But, thanks to Kate and Wills, we have been graced with an extra 4 day weekend this year. So we are going to take the opportunity to recable the entire room. Several codenodes for the projects have been suggested, including “project subu”, but we eventually settled on “The Big Weekend”

So, starting at 1800 on the 28th April, we are going to remove every single cable, all the switches, all the old cable management rails, and re-do the lot! We have until 0700 on Tuesday 03rd May to get everyone done. I’ve drafted in most people in IT to help out (The desktop Guys, Server Guys, Helpdesk Guys, even the Head of Infrastructure) so there will be around 10 of us working in shifts around the clock to get it completed. We hope to be finished for early on the Monday giving us enough time to go around the offices testing everything.

One of the major problems at the moment is that the cabinet layout was poorly planned in the first place, all the switches are located at the top of the cabinets, meaning the floor ports at the bottom need long cables to reach the top, which results in lots of slack which needs to be dealt with! So first on the agenda will be to move all the patch rails around in order for the switches to be distributed evenly across the cabinet (top, middle, bottom) meaning that you should never need more than a meter cable to reach a switch, with most of the cables being 0.5meter.

We have done a “test run” of sorts on a single cabinet, I don’t have any before pictures, but the after picture should give you an idea of the look we are going for!

We are going to set up a webcam on a 10 second time lapse to capture the action as it happens, and obviously lots of photos will be taken over the weekend so there is an everlasting record of our Big Weekend.

More to come
But in the mean time, here are some pictures for your viewing pleasure….sorry about the quality, but what do you want from a blackberry!!!!

My initial idea was to deploy a TACACS+ server, but no one wanted to spend on Cisco’s ACS and I couldn’t find a decent free one, so i looked at using Radius with Active Directory.

It turns out it’s actually quite easy to set up and administer!

Firstly, if you have more than 50 devices, you will need Windows Server Enterprise or Datacentre (2k3 or 2k8), or several servers, because Server Standard only supports 50 radius clients.

To start with you need to install he radius service on Windows, in 2003 this is called IAS (Internet Authentication Service) in 2008 this is called NPS (Network Policy Service). I’m not going to go over the install of this here as it’s quite simple, but follow the links below for more info

2003 – http://technet.microsoft.com/en-us/library/cc781690%28WS.10%29.aspx
2008 – http://technet.microsoft.com/en-us/library/cc725922%28WS.10%29.aspx

Next you need to set up the Radius Policy, at the moment i have only done this in 2003 as this i what i had when i set it up, i indent to move it over to 2008 once our Windows team have built the server for me!!! but i believe the process is pretty similar.

First Step, open us the IAS MMC, and right-click on the Remote Access Policies branch and select “New Remote Access Policy” you should get the below window;

Select “Setup a Customer Policy” and give it a name, press Next..

Next you will need to set “Policy Conditions” – these are what defines which users can access the devices. We are going to be using an Active Directory group to grant access, so members of this group will be allowed to login. Click Add and look for “Windows-Groups” (usually the last on the list) From here you can choose you group, it can be a local group on the server or an Active Directory group. Once you have selected your group it should look like this;

At the next window, you will define if this policy Grants or Deny’s access, the default is Deny, so make sure you change it! Next you will be asked to edit the Profile, this is where the magic happens! There are several changes you need to make in order for Radius to work.

1) Select Authentication, Select “unencrypted authentication”, uncheck everything else (Cisco on seems to support PAP, if anyone has a way to make it support CHAP, please let me know!!)

2) Go to the Advanced Tab, and remote the two attributes that are there by default. Now click “Add” and select “Vendor-Specific” from the list, click “Add” again on the window that pops up (This should be the “Multivalued Attribute Information” windows) Select “Cisco” from the drop down list, and say select “Yes, it conforms”

Now click “Configure Attribute”, Change the attribute number to 1, lease the format as string and enter the below as the value (enter is exactly as it appears in red below)

shell:priv-lvl=15

If you wanted to assigned a different privilege level to someone, you can do it here. (i.e. several different AD groups to assign several different privilege levels). Ok everything untill you get back to the “Add Attribute” window, click Add to add you Vendor Specific Attribute, the window wont close, but it does add it, you now need to add another Attribute – “Service-Type” – Change the Attribute Value to “Login” and click OK, add this again and now click close, you should now see the below;

And that is you Policy Done!

Now. time to add a client to the IAS and configure the Cisco Device.

1) Add a client to your radius – In the IAS MMC, right-click on the “Radius Clients” branch and choose “New Radius Client” Enter the Display anem and IP address of the device, click next. Change the Vendor to “Cisco” and enter your shared secret (keep a note of this for later)

2) Configure the Cisco Device.

First, you need to configure the device to use AAA by entering the command

aaa new-model

Then you need to configure the AAA Groups, There are 3 parts to AAA

Authentication – Who is allowed to login
Authorization -  What are you allowed to do once you have logged in
Accounting – What are you doing once you are logged in

We are only going to be concerned with the first to A’s – Authentication and Authorization, enter the following commands;

aaa authentication login default local group radius
aaa authorization exec default local group radius

This will create a authentication list called “default” you can name it what you want, but if you use default you don’t need to modify anything else.

The list defines what source the router users to authenticate you – i.e. Local usernames first, then the radius server.

Next you need to configure the Radius Server;

radius-server host 10.10.10.10 auth-port 1645 acct-port 1646 key SHAREDSECRET

the Host IP is the IP of the server, and the Key is the shared secret you entered into IAS.

If you device has multiple interfaces or routes to the IAS server, you might want to configure a source interface (i.e. the interface with the IP you entered into IAS);

ip radius source-interface Vlan1

And thats it, you should be done! give it a go.

The only extra is if you used your own name for the AAA List, you configure your VTY lines to user this list, type the following;

line vty 0 15
login authentication MYLISTNAME