Skip navigation

SNMP - the Simple Network Management Protocol - is a pretty cool protocol to get to know and no matter how well you know - it there's always a bit more to learn. As a network engineer or system administrator your first exposure to SNMP was probably through using a Network Management System (NMS) like Orion NPM or HPOV or an Element Management System (EMS) like CiscoWorks or IronView.  These applications use SNMP to monitor and or configure devices on the network.

What you may not know is that SNMP is a great tool for troubleshooting. Back in the old days, network engineers like me would do a lot of our troubleshooting from Unix hosts and we'd use Perl to create little scripts and tools to help us troubleshoot network issues and performance. For instance, if you saw a device that was going up and down you might write a script to continually ping the device and record response times and then place that script on unix hosts at a few different locations on your network. A more advanced use would be to write a script to use SNMP to pull stats from a device in real-time and then store those results for analysis. Because SNMP is so widely deployed and the MIBs are standardized across devices a simple tool can have broad applicability.

Nowadays there are packages tools that make network troubleshooting and real-time monitoring a lot easier. The Engineer's Toolset that we offer here at SolarWinds is a great example of that. We started writing these tools several years ago when we were doing a lot of network consulting and needed tools to help us quickly discover and document the customers' networks and to isolate network issues and provide real-time monitoring while we were optimizing configurations. It's hard for me to imagine being able to do some of the projects that I've done without having the Engineer's Toolset handy.

As you go about trying to learn about SNMP, grab the Engineer's Toolset. Even if you don't buy it, the evaluation version will fall back to a free version that includes about 15 tools that are tremendously useful. Strive to understand the protocol, the underlying MIB and OID structures, and the different authentication methods (SNMPv2C vs. SNMPv3). Trust me, it'll come in handy...


Flame on...
Josh
Follow me on Twitter

If you've ever worked as an IT administrator of any kind - network engineer, systems engineer, server admin, VMWare administrator, SAN admin, security engineer, VoIP engineer, webmaster - whatever - you've probably worked with our little friend "ping". However, knowing how to ping isn't the same thing as knowing ping...

ICMP (the protocol that ping uses) is one of the most commonly used and valuable protocols when it comes to analyzing, monitoring, and troubleshooting networks. Most network managaement tools use ICMP to measure and report on statistics like status, availability, reachability, latency, and response time. In some cases even tools like traceroute leverage ICMP as well. Ping packets can be tweaked to fit in many different situations by changing the size of the packet, setting the discard eligible bit, and by tweaking the treatment of ICMP along the path.

Do yourself a favor and get really familiar with ping. Grab a copy of Wireshark and capture some ping packets and analyze them. Understand the parts and understand how your networks treat ping packets under differnet situations (security, load, source, size) and you'll be glad you did one of these days...


Flame on...
Josh
Follow me on Twitter

Back in the old days we as engineers used to live and die by the CLI (Command Line Interface). I can remember days when fighting a fire on the network meant having 20 different telnet windows open and alt-tabbing between them as I displayed my technical wizadry with Cisco's CLI - whipping back routing loops, spanning tree problems, and broadcast storms like a circus trainer controls a pack of hungry lions. All the while putting the technical neophytes standing around me watching into a state of awe comparable to the way that Luke Skywalker was awed when Yoda lifted the x-wing tie fighter from the swamp and placed it safely on dry ground using the Force... Yeah, I said it - shock and awe level CLI skills. Jedi level CLI skills. Eat your heart out Napoleon Dynamite... Wow, those were the days!!!

Nowadays you can do a lot of your work without having to drop to a CLI. In many cases, web GUIs have replaced telnet and SSH and the days of using Cisco's CLI to edit your router config or using the command-line to change the configuration of your Linux server's configuration are somewhat behind us. A lot of today's "experts" will tell you that the CLI is to be avoided and that with today's technology it's an unnecessary skill.

I'm here to tell you - don't believe it for a second. Learn the CLI. Start out with either Cisco's CLI or the command-prompt on a Linux machine (whichever you have easier access to) and go from there. The key here is to get comfortable working in this mode. Everybody's CLI is a little different so don't worry so much about syntax. Most of today's network gear has a CLI that is based on Cisco's. Many hardware vendors even advertise a "Cisco-like CLI", so starting there is a great choice.

There's quite a bit of free help available online and some of the free CCNA study guides and labs are a great way to get some exposure; but, bottom line - dive in and get your hands dirty... The best way to learn this stuff is by doing it.

Trust me, there will be times when you need to be able to work from just an IP address and an SSH client and go from there. Download a copy of puTTY for free and keep a copy on every system that you work from. Someday you'll thank me...


Flame on...
Josh
Follow me on Twitter

Last week I gave several presentations at Cisco Live (Networkers) in Las Vegas. As usual, I preferred to discuss rather than present, and so I ended up in lots of discussions with folks from the IT infrastructure teams of organizations from around the world about the challenges that they face. No matter whether they were network engineers, systems administrators, or storage admins; one thing that really stuck out to me after all of these conversations is that technology is evolving much, much faster than most of us can learn and/or adopt it. Some of the technologies that seem like old news to part of the crowed was brand new to others and the reverse was true as well.

In an effort to help with this, I'm going to dedicate 10 blog posts to highlighting and explaining technologies that everyone should be aware of and consider implmenting within their organizations. By no means are these the top 10 technologies overall as I'm going to skip over all of the fundamentals and things that I think that just about everyone already knows about or has in place. Instead, I'm going to focus on technologies that are commonly overlooked or unknown even though they can be tremendous assets.

The first technology that we're going to cover is Cisco IP SLA. For a technical definition I'd recommend visiting Cisco or Wikipedia but here's a simple explanation of what it does and how to use it.

When you think about enterprise networks today, one theme is common - our users and our resources are more distributed than ever before. Sure, we may be consolidating our datacenters but chances are that we're also moving things out of our datacenters and leveraging SaaS providers, colocation facilities, public cloud providers, and public internet resources. Most of our networks have several different sites - all with multiple connections back to the corporate network and a direct internet connection. Our users are spread all over the place - main office, remote offices, home offices (telecommuters), shared office (like Next Space). Even in the datacenter, with virtualization technologies, we're commonly distributing components of what used to be a "server" across several virtual servers which may be distributed across several physical server clusters.

These facts force us to think about monitoring a little differently. It's easy to see that tracking application and resource availability and performance from the users' perspectives can be quite challenging. Cisco IP SLA helps conquer this challenge.

Efffectively, Cisco IP SLA or Cisco IP Service Level Agreements lets you have the routers distributed across your network runs tests and compute metrics from their location (their perspective) out on the network. Some of the most common measurements that people measure from remote locations using Cisco IP SLA are VoIP performance (jitter, packet loss, latency), ping (for general latency and reachability), HTTP availability and performance (to key web apps like your SaaS providers), DNS (hey, if DNS is slow from a remote site then everything's pretty much gonna seem slow), and so on.

Best in class network monitoring applications, like the Orion IP SLA Manager, make using Cisco IP SLA easy by configuring and managing the IP SLA operations and pulling the results into a central console for easy analysis, alerting, reporting, and trending. This technology is quite mature, both Cisco IP SLA and the Orion IP SLA Manager, and can be trusted to be deployed on today's mission critical networks.

If you'd like to learn more about this technology visit our Geek's Guide on Cisco IP SLA.  There you'll find recorded webcasts, videos, white papers, and free tools that can teach you all you need to know about this cool and often overlooked technology...


Flame on...
Josh
Follow me on Twitter

Filter Blog

By date: By tag: