A couple of years ago, one of the top salespeople in our company was sitting across from me. He was working with a major school system interested in a large hardware refresh, including a new wireless and VoIP infrastructure.
To me this was a typical project, with typical hardware, typical licensing, and a typical scope. Needless to say I felt like the expert in the room.
So when the salesperson challenged me about hardware and considerations for deploying QoS policies, I was offended.
What did he know about QoS? What did he know about LAN switching? My solution was simple: buy Catalyst switches of varying platforms and do a huge hardware refresh.
This meant manually configuring custom QoS policies on every device. You see, the Catalyst 4500X wouldn’t support auto QoS on the port-channels, so we needed to do it all by hand.
The salesperson wouldn’t buy it, though. He rolled his eyes and said there must be a better way. He mentioned some heathen brand of switch that would deploy policy throughout an entire network with a few mouse clicks.
I was outraged. As a network engineer, I enjoyed getting into configs. I didn’t care about efficiency. I didn’t care about automation. I didn’t care about doing it a better way. I knew the CLI, and I knew Cisco. How dare he?
But deep down I knew he was right. Of course it was completely inefficient to configure everything by hand. Imagine how many errors my team and I would have made copying and pasting DSCP maps and AAA configurations over hundreds of switches!
And even if we didn’t make many errors, accessing every device by hand would take forever. The conflict I experienced wasn’t a matter of logic or reason – it was a matter of comfort level and pride.
It took me several months before I could say out loud that his approach was the way to go. But why? Network engineers generally pride themselves in learning new technology and staying flexible.
I think it was because I’d grown comfortable with a blinking cursor and a humming fan. It was safe, and it was what I knew.
I brought up my dilemma with my father-in-law, who also works in IT. He reminded me that I successfully changed careers in my mid-20s from teaching English to networking, though it took considerable effort.
Was it so difficult to believe that I couldn’t change again?
The scales fell from my eyes. I needed to put in the effort to learn a better way to do networking, just like I learned how to do traditional networking 10 years ago. I knew logically that it made so much more sense, but I just needed the switch to flip in my brain.
I still see reluctance among colleagues to accept managing a LAN with software. Whether it’s a lack of skill, or a mindset that resists doing something differently, the switch hasn’t flipped for some people.
As a recent convert, I embrace this new paradigm just as I would embrace a better way of doing anything. It’s more efficient. It’s less prone to error. It just makes sense. And as much as I hate to admit it, the sales person was right.
As a professional in the IT sector, I’ve always heard the hype about Cisco products and how difficult they were to configure. While looking at job postings, many of them had the CCNA certification as a requirement for consideration. I’ve always wondered why this was the case as most small and medium scale enterprise use a variety of network devices from different vendors. Surely, Cisco cannot have precedence over all of them. I believe one should have a solid understanding of network and system administration principles to be able to build, configure and administer a network environment using any network device available to you. As a result of this orientation, I was always sceptical about taking a Cisco certification.
My first encounter with a Cisco product came while I was employed in a high end nursery school. The proprietor of the nursery had purchased a Cisco 1800 series router and a Cisco adaptive security appliance device together with a couple of Netgear managed switches. I thought to myself, this should all be fairly easy to configure considering the network topology of the nursery.
We decided to create two VLANs to handle data and video services respectively. The managed Netgear switches were very easy to configure as they had a user-friendly Graphical User interface (GUI). All you have to do is to connect a pc to an Ethernet port on the switch and type in an administrative IP address on a web browser and you were in.
The Cisco 1800 series router on the other hand was a different kettle of tea. First, you have to connect your pc to the router using a console port cable. Most PCs today do not have a console port, so you have to get a console to USB adapter and install the drivers on your PC before you can attempt a connection. Once the connection was established, I had to figure out how to configure the Cisco router using the command line interface (CLI) as there was no GUI.
I and a colleague of mine carried out some research using Google, the Cisco website and lots of technical blogs out there on the internet. We first had to figure out that some commands run only in privilege mode or in global configuration mode or in interface configuration mode. Then we learnt how to create user names and secret passwords and how to configure access to the router via Telnet and SSH. After that, we decided to use the router as as DHCP server as our windows server had licensing issues at the time. we then figured out how to configure VLANs on the router interfaces and finally, we concluded with the NAT configurations.
Some of the commands we used:
enable secret 5 blablahashblah
enable password chima
ip dhcp excluded-address 192.168.90.1 192.168.90.50
ip dhcp excluded-address 192.168.50.1 192.168.50.50
ip dhcp pool video
network 192.168.90.0 255.255.255.0
ip dhcp pool Data
network 192.168.50.0 255.255.255.0
multilink bundle-name authenticated
username chima privilege 15 password 0 blablabla
no ip address
no mop enabled
encapsulation dot1Q 50
ip address 192.168.50.1 255.255.255.0
ip nat inside
encapsulation dot1Q 90
ip address 192.168.90.1 255.255.255.0
ip nat inside
ip address 220.127.116.11 255.255.255.252
ip nat outside
ip forward-protocol nd
no ip http server
ip nat source list 10 interface FastEthernet0/1 overload
ip nat inside source list 10 interface FastEthernet0/1 overload
ip route 0.0.0.0 0.0.0.0 192.168.2.1
ip route 0.0.0.0 0.0.0.0 18.104.22.168
access-list 10 permit 192.168.0.0 0.0.255.255
line con 0
line aux 0
line vty 0 4
privilege level 15
transport input all
scheduler allocate 20000 1000
Passwords and IP address details have been changed
At the end of this scenario, we had a fully configured LAN with access to the internet. My experience with Linux CLI made it easier for me to use the Cisco CLI and I realised that it is much more easier to administer a Cisco device using the CLI.
These challenges convinced me of the necessity to educate myself on Cisco routing and switching technologies. Since then, I have started the CCNA routing and switching course and I have learnt a whole lot about networking in general and Cisco device configuration in particular.
While working at a certain NGO, I was tasked with creating and adding email signatures on all the Ipads, MacBooks and Imacs used for communication with business clients. This sounds like an easy enough job to do, but I experienced quite a couple of issues while carrying out this task. This is a description of the issues I experienced and the solution I arrived at. Continue reading “My Email Signature Nightmare”