Tag: Random Thoughts

Studying for CCDA

I’ve decided to start studying for the CCDA. I haven’t taken any tests for awhile and I’d like to start down the road to renewing my CCNP R&S (which admittedly won’t expire for another 26 months). I plan to knock out the CCDA before November is over and then the CCDP by the end of February 2019.

My normal study patterns are typically loose and I don’t set any deadlines. I am still usually able to achieve goals in this fashion. This time however, I’m setting weekly goals of material to cover and will work every hard to ensure I stay on path. Part of the reason I am doing this is to determine how well I can stick to a schedule, as I might entertain studying for the CCIE R&S after this. I’m not 100% committed to that path though as I learn more about network automation and spend a good chunk of my free time on other skills that I think are useful and valuable.

I may be posting some of my notes on the CCDA going forward. I haven’t seen too many online resources for CCDA, and I hope it helps someone else studying.

This Guy Logged Putty to a Network Share and You Won’t Believe What Happened Next

It turns out that logging putty sessions to a network share is, or can be a bad idea. I learned this after getting a new laptop at a new job. I had several workstations and wanted to log all of my putty sessions to the same folder – I figured this would help with troubleshooting at some point down the line. What I didn’t realize was that this would cripple me for a few days as I worked and tried to figure out why my sessions were so slow.

It didn’t help that I had just bought a sketchy USB-to-serial cable and was questioning the drivers I had installed. Putty sessions would often hang before I could even login to a device. How frustrating! I realized that when I was connected to a wireless network I had the most issues – using a wired connection was typically no trouble at all. At some point in troubleshooting almost any strange issue, I turn to Wireshark. Wireshark can be a great tool when you have a defined problem scope, which I didn’t quite have here – but I was on the verge of something.

I saw a lot of chatty SMB traffic going back and forth between my laptop and a file server. The destination folder matched my putty log folder. Suddenly it hit me – the added latency of a wireless connection combined with the chatty nature of the SMB traffic caused all of the ssh sessions from my laptop to be mostly unusable. So obvious and clear, why hadn’t I thought of it sooner? As soon as I changed the logging path to a local drive, my sessions sped up dramatically.

This is a strange problem that I suspect won’t help anyone specifically – but I do hope it’s at least mildly interesting.

No Safe Changes

Settling into a new job – I was working on what I thought was a routine change. Setup a spare switch in a temporary location with a basic config. Easy enough, right? The time came for me to configure a port on the upstream device. The device in question was a legacy Catalyst 65xx – a big chassis switch that I had read about but never had any experience with. The port I was going to use had a dozen lines of configuration already applied – mostly related to queuing. My first instinct was to issue a ‘default interface <slot/port>’ command and start from scratch. This is almost always the right thing to do, as it ensures no confusing stale configuration remains (I’m looking at you ‘switchport access vlan # / switchport mode trunk’).

Leaning over, I asked my co-worker if the ‘default interface’ command worked on these things. After being assured that it would be fine, I held my breathe and pressed ‘enter’.

I was greeted with several lines of output related to quality of service (QoS) being set to default values on a range of interfaces. Crap! Had I just wiped out the configuration for an entire line card?

No – it turns out the architecture of these switches is such that the queuing must be configured identically on specific groups of ports. I forget if it was all 48 ports on the card, or  16, or whatever, but the point is that I made a simple change and there were unintended consequences. At least Cisco was kind enough to leave me a message about it. And it didn’t bring the network down.

This was a reminder that even the most mundane, routine, everyday changes can go sideways when you least suspect it.

New Opportunities

I have recently gone through some life changes which means I have less time to blog than I’d like. I wanted to publish a new post every week or two, however with the transition I have been busier than usual. The good news is that when I can regularly post again, I should have a lot of new content to share! Sorry for the extended absence – I hope to be back in the swing of things shortly.

When Should You Automate Something?

Automation has been hot in the networking world for quite some time now – however I still see many people asking for advice on how to get started. If you don’t know of a project or something you can do for fun, think some more.

Others ask at what point they should start automating tasks. Some like to break the answer down to a simple equation where if (time to automate task) < (time to complete task manually),  you should clearly automate.

def should_i_automate(time_to_do_manually, time_to_automate):
    if time_to_do_manually > time_to_automate:
        return “You should automate this task!”
    else:
        return “You should do this manually!”

This leaves out the intangible benefits of skills learned while automating tasks that can be leveraged in the future. It leaves out the hard-to-quantify human errors that are avoided when humans are removed from repetitive tasks. I don’t know about you, but I find coding to be challenging and rewarding as well. These are just a few reasons why you may automate something even when the time payout isn’t immediate. What are your thoughts?