-
09.07.09
working on the new office network
Most of the new network equipment has turned up at work, and so I’ve been working on getting it all configured. Sadly the main core switch has not turned up so we’ve had to improvise, using an old 3550 L3 switch to pretend to be the core switch for the time being. VTP allows a little bit of the work to be automated, as when we turn on the new core switch, we can configure VTP and all our VLANs will magically appear. For the rest of the work, such as the L3 SVIs, ACLs and any other config work we’ve done on the “core switch,” this can be copied/pasted from what we’ve done so far so nothing should be wasted.
Essentially the network (in very basic form!) looks a little like this:
We have the KPSN CPE router which also hosts the wireless LAN controller, an add-in module for the 3825 router (and all modular ISR routers). Connected to this we have the core switch, which will eventually be a Cisco 4506, and assorted workgroup switches which will be 2960s and 3560s.Getting the wireless piece working was a challenge. Having not configured a wireless LAN controller before, this was an excercise fraught with Google searching and reading articles from the Cisco website. As the WLC had previously been deployed we wanted to factory reset it. Most of the articles were along the lines of “once you’ve done the incredibly trivial task of getting your access points associated with your controller all this is child’s play.” Having reset the WLC, configured it, set the clock on it (important for access point association), configured DHCP option 42 (and another that escapes me at the moment) we still couldn’t get the access points associated. Eventually we found that because the APs has also previously been deployed and had self signed certificates (SSCs) we had to sit on the debug of the WLC, capture the SSC and add it into the configuration of the WLC. Once we had done this the APs associated and joined the WLC fine. This took care of 5 out of the 6 APs, but one was still in “autonomous” mode.
A Cisco autonomous AP is an independent (as you might imagine) access point which you individually configure, and has a standalone image. You can “upgrade” an autonomous AP to remove its intelligence and make it a Lightweight Access Point (LWAP), and that’s what we had to do with the final AP. Having discovered that Cisco meant what they said about running the update tool on Windows XP (and not Vista / Windows 7 like I was initially trying) we eventually had the final AP all joined on as an LWAP.
Having done the heavy lifting with the wireless network, we now just need to spend some time tidying a few things up, deploying a RADIUS server to authenticate the wireless network against, configure some NAT to allow us to talk to head office, a bit of port security and the basic network is in place. Following that we need to revisit the connection to our remote office to make things a little more efficient and secure there, and just continue to evolve, improve and secure the new LAN infrastructure.
Hopefully soon afterwards our server infrastructure will arrive and we’ll really see a big difference in performance.
-
03.17.09
bad day at the office
It’s been a bad day at work today. We authorised a change to our filtering system which upset a lot of people, and then when those people complained, we pushed back against the complaints. Bad news all round – a lot of extra work for my team, and lots and lots of unhappy customers, a definite big fat FAIL.
I should start by saying that up front I was in favour of the change, we actually thought that the change was already in place, and it was a surprise to us last week to learn that it wasn’t, so after some internal debate we raised a change to fix the situation. However, minutes after the change went live this morning there were people calling in to complain that we had taken away some of their access, and that they wanted it back. After about the third report of this I threw it over to our project team.
What I had hoped and campaigned for was that we would revoke the change, admit error, take it back and re-think. What I got was a decision that this was policy and that we should run with it. I instructed my team accordingly and we got on with it.
The end result was that each of us took call after call, email after email from people unhappy about the change, and we had to deal with it. It’s easy to make unpopular policy decisions when you don’t have to deal with the consequences, isn’t it. It’s a bad day when every call you take is from someone who wants your head on a plate and tells you that you’ve screwed up their day.
Come the end of the day certainly the folks in my team had had enough. The change was made with the intention of furthering protection for children, which it does certainly achieve by denying access to the resources, but at what cost. Sometimes you have to make a decision based on cost/benefit analysis and not based upon Utopian ideals that “everything should be this way so let’s force it to be this way,” it just doesn’t work.
Tomorrow is another day.