The Basics of Network Troubleshooting

The following post is something I wrote as an in-house primer for our help desk staff. While it a bit down level from a lot of the content here I find more and more the picking and reliably going with a troubleshooting methodology is somewhat of a lost art. If you are just getting started in networking or are troubleshooting connectivity issues at your home or SMB this would be a great place to start. We often get issues which are reported as application issues but end up being network related. There are a number steps and logical thought processes that can make dealing with even the most difficult network issues easy to troubleshoot. The purpose of this post is to outline many of the basic steps of troubleshooting network issues, past that it’s time to reach out and ask for assistance. Understand the basics of OSI model based troubleshooting The conceptual idea of how a network operates within a single node (computer, smartphone, printer, etc.) is defined by something called the OSI reference model. The OSI model breaks down the operations of a network into 7 layers, each of which is reliant on success at the layers below it (inbound traffic) and above it (outbound traffic). The layers (with some corresponding protocols you’ll recognize) are: 7. Application: app needs to send/receive something (HTTP, HTTPS, FTP, anything that the user touches and begins/ends network transmission) 6. Presentation: formatting & encryption (VPN and DNS host names) 5. Session: interhost communication (nothing …

Configuring Networking for Nimble-vSphere iSCSI

One of my last tasks for 2014 was integrating a new Nimble Storage array into our environment. As this is the first of these I’ve encountered and I haven’t been able to take the free one day Nimble Installation and Operation Professional (NIOP) course they provide I was left to feeling my way through it with great help from their documentation and only ended up calling support to resolve a bug related to upgrading from 2.14 of the Nimble OS. On the network side our datacenter is powered by Cisco Nexus 3000 series switches, also a new addition for us recently. These allowed us to use our existing Cat6 copper infrastructure while increasing our bandwidth to 10 GbE. In this post I’m going to document some of the setup required to meet the best practices outlined in Nimble’s Networking Best Practices Guide when setting up your system with redundant NX-OS switches.

Updating the Code of a ipbase Licensed Cisco Catalyst 3750X Switch Stack

Here in the office the Access Layer of our switching infrastructure is handled completely with a 7 unit stack of Cisco 3750X switches.  There is no need for these to do any routing other than intervlan so when purchased 3 years ago we just ordered the IP Base licensing level.  Well from what I can tell there is a universal code base and a licensed feature level of each code revision.  The universal naming convention looks like c3750e-universalk9-mz.122-55.SE1 while the ipbase looks like  c3750e-ipbasek9-mz.150-2.SE6.  What I found is that I do not have the ability to download the universal code of later releases due to my licensing level and possibly the lack of SmartNet I keep on these, but I do have access to the ipbase code.  When attempting to update the code on this stack I was presented with the error

After some searching I found reference to others trying to go from IP Base to Advanced IP Services code having to put the /allow-feature-upgrade switch on the archive download-sw code in order to allow the upgrade as well as it seems a downgrade.  Evidently this feature came about with IOS version 12.2(35).  Now the upgrade progressed and I have happy little upgrades switches.

Another note about this upgrade I found in the official release notes is any upgrade from 15.0(2)SE to later will result in a microcode upgrade which when unmitigated will lead to an exceptionally long restart of the switch.  You can mitigate this either by using …