The Recabling = Completed!

Following on from my last post, we have completed the recabling of our upstairs comms room. We had 4 days to complete the work, and managed to complete it after around 55 hours working around the clock – well ahead of schedule!

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;

Read more of this post


Recabling Project

Before I even started at my current job, I had heard rumours of the “upstairs comms room”.

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”

Read more of this post

Using Active Directory for Radius Authentication

When i started at my current job about 12 months ago, there was no means of centralized authentication. All the equipment used generic logins, and every device was different, so you need a spreadsheet of logins just to do the simplest of tasks!

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.

Read more of this post

DMVPN – The Config

So following on from my last post, I have come up with a topology to test a DMVPN Solution;

My Plan is to use setup DMVPN with R1 & R2 forming the “Hub” site, and R3 forming the “Spoke” site, R5 is just there to add an additional layer to the IGP I will be using (probably EIGRP, as I believe OSPF can have problems running over a DMVPN due to its link-state nature)

If you’re wondering where R4 is, its forming my “Internet” cloud.

I haven’t really included IP addressing on this diagram, but if you see address in the config, I have used this range to simulate the public address space. with representing the private address space.

This setup is what is technically called a dual cloud DMVPN setup, as there are two DMVPN tunnels going to each spoke, this provides redundancy should there be a failure of one of the routers at the hub.

There are two ways to direct traffic flows with this dual cloud setup, you could use your IGP to load balance across both tunnels, or you could set the metric of one of the tunnels so that one is prefered and one is secondary, I don’t really see much problem with either option, I guess its down to personal preference unless someone can suggest otherwise.

Read more of this post

VPN Technologies

At work we are looking at moving over to a new ISP, so will take the opportunity to deploy a new edge module to replace are current crumbling poorly designed mess (implemented before i started i might add!)

Part of this will be looking at alternative VPN solutions, at the moment we use a pair of ASA’s in the UK, and 1801 routers at our remote sites, they are running Site-to-Site IPsec Crypto Maps, with static routes pointing at the ASA’s.

My problem with this setup is the interesting traffic ACL’s, they always cause a headache, they never work right first time, and can be a pain to troubleshoot, and then there’s the NATting issues….

Read more of this post

EIGRP Authentication Part II

So after thinking about how to implement key-chains around my network, I decided the best way would be to have a setup that has a new key every month, with a little overlap from when one key ends to the next key starts, to account for differences in NTP – realistically a few second difference would be too much, but I’ll allow for an hour just in case.

I’ve made a spreadsheet which generates random strings for use as keys, and using the times/dates entered, generates some config (EIGRP Key Chains Spreadsheet) I can then push this out to all my routers with Solarwinds NCM to make sure the same key-chain is everywhere. In theory you can use a different key chain for every router pair, but I felt the admin overhead on this was way too much, even on a relatively small network.

Read on for the config…. Read more of this post

EIGRP Authentication

I imagine most networks use EIGRP Authentication on the interfaces that are enabled for EIGRP;

R01(config)#int fa0/1
R01(config-if)# ip authentication mode eigrp 1 md5
R01(config-if)# ip authentication key-chain eigrp 1 MYKEYS

Usually i only see people using the one key with the send/accept lifetimes set to infinite.

I am reviewing the security on our network, and am debating whether or not to implement keys with a set lifetime?

I have always been put off doing this in the past due to the issues with making sure the key lifetimes overlap, below is a sample I’ve been working on in my lab using 1 minute keys with 30 second overlap at either side of the key lifetime;

key chain MYKEYS
key 1
key-string 1111
accept-lifetime local 16:39:30 Mar 27 2011 duration 120
send-lifetime local 16:40:00 Mar 27 2011 duration 60
key 2
key-string 2222
accept-lifetime local 16:40:30 Mar 27 2011 duration 120
send-lifetime local 16:41:00 Mar 27 2011 duration 60
key 3
key-string 3333
accept-lifetime local 16:41:30 Mar 27 2011 duration 120
send-lifetime local 16:42:00 Mar 27 2011 duration 60
key 4
key-string 4444
accept-lifetime local 16:42:30 Mar 27 2011 duration 120
send-lifetime local 16:43:00 Mar 27 2011 duration 60

Obviously in a production environment, you wouldn’t use such short durations, i think maybe a month per key would be about right. With the last key send/accept lifetime set to infinite to prevent the key-chain from expiring if new ones are not added in time and causing an outage.

the “show key chain” is alway quite useful if this is something you are new too;

R02#show key chain
Key-chain MYKEYS:
key 1 -- text "1111"
accept lifetime (16:39:30 BST Mar 27 2011) - (120 seconds) [valid now]
send lifetime (16:40:00 BST Mar 27 2011) - (60 seconds)
key 2 -- text "2222"
accept lifetime (16:40:30 BST Mar 27 2011) - (120 seconds) [valid now]
send lifetime (16:41:00 BST Mar 27 2011) - (60 seconds) [valid now]
key 3 -- text "3333"
accept lifetime (16:41:30 BST Mar 27 2011) - (120 seconds)
send lifetime (16:42:00 BST Mar 27 2011) - (60 seconds)
key 4 -- text "4444"
accept lifetime (16:42:30 BST Mar 27 2011) - (120 seconds)
send lifetime (16:43:00 BST Mar 27 2011) - (60 seconds)

All in all I think this is something that would be quite acceptable and not to much of an admin overhead with a proper planning.

The final question – do we use the same key chain on all routers/interfaces, or use multiple key chains, but then I can see the administration getting excessive!