Skip navigation

Every once and a while I get to do something really, really cool. No, it's not the same kind of cool as when my buddy Chris dated the co-captains of the kvanzant squad (twins no less) while he was in college there or yesterday when my pal Mark and his 2 hunting partners ended up with 4 gobblers in a single morning. Come to think of it, it's not the same kind of cool as when my friend Kramer got that job modeling underwear for Calvin Klein or when my friend kvanzant was recruited as one of the stunt men in Joe Dirt.

But, as a guy that's so geeky that if you cut me I bleed ones and zeros, quite frankly I can't imagine anything cooler than being able to announce our new products for helping our customers with their IP address management needs and being able to do it by introducing both a new FREE tool and a new module for Orion - the Orion IP Address Manager.

This is cool not just because it's a topic near and dear to my heart or because I've been tracking IP addresses in spreadsheets since Excel had a 64K row limit and I had to have multiple files just to track my entire address space. It's cool because our customers have been asking for this functionality for a long time and now it's here, it's easy to use, and it's affordable.

So, tonight I'm going to go home and celebrate a little. I think I'll light up the fireplace and burn some old IP address spreadsheets I've been saving. Maybe I'll even have a glass of wine, one of those cuban cigars I snuck back from Cisco Networkers in Barcelona, and maybe even watch a bit of Joe Dirt on the TiVo. Yes, life is good...


Flame on...
Josh
Follow me on Twitter

This week I've been out in Denver attending the annual IPv6 Summit put on by the Rocky Mountain IPv6 Task Force. It was a fantastic conference and the fact that it's free is almost too good to be true.

I first got interested in this particular conference because two of the speakers are old buddies of mine from my days back at INS. Scott Hogg and Jeff Doyle are two of the sharpest people I've ever met and really know their stuff when it comes to IPv6. The content at the show was great but the best part was the collaboration that took place during the breaks and lunches.

There were several great presentations - Scott's presentation on IPv6 Security and Jeff's "stories from the field" about deploying IPv6 were awesome. My favorite was Stan Barber's talk on "Daily Living with IPv6" where he talked about the advantages and challenges of using IPv6 at home.  It got me so fired up that I have decided to convert to IPv6 at home. I don't expect any problems with my hosts as they're all XP and/or Leopard but I do have some appliances (AppleTV, iPhones, DVRs, game consoles, etc) that may prove to be challenging.

So, in a nutshell, yeah, I'm drinking the Kool-Aid. As a matter of fact you can call me the Kool-Aid Man. IPv6 is cool, it's easy, and it's on its way. If you're running any IPv6 stuff in your lab you can visit SolarWinds.com to download the latest Engineer's Toolset as it natively supports IPv6 today.


Flame on...
Josh
Follow me on Twitter

IP based networks are more complex today than ever before. Not only are they now supporting voice, video, and data, but complications like dwindling IPv4 resources, sprinkles of IPv6, and constant changes in topology can make them seem almost unmanageable. Tactical networks have all of these complexities with the added pressures of needing to be deployed quickly, by a sometimes untrained and ever-changing staff, and with consequences of failure measured in more important things than lost packets…


 


The good news is that there are some best practices that you can adopt when it comes to troubleshooting issues within these tactical networks. I’ve developed this list of practices after working with several large tactical networks including some within the US Air Force, the Special Operations Command (SOCOM), the US Army’s Warfighter Information Network-Tactical (WIN-T), the Navy’s Littoral Combat Ship (LCS) systems, and many others and I certainly can’t take much, if any, of the credit as those folks really know their stuff and have shown me many things over the years.


 


The first tactic that I find to be invaluable when it comes to managing these networks is documentation. Keeping an updated diagram of the network (whether it’s in Visio, in a notebook, or drawn in the sand) is the first and foremost step in speeding up the troubleshooting process. There are some great applications like LANsurveyor that can make this a lot easier.


 


Next, you need to be able to troubleshoot from different perspectives on the network. If you’re in DC and a user in Dallas is complaining about performance of a web application based in San Jose, it’s going to be hard for you to troubleshoot if your only perspective is that of your NMS in DC. This is where technology like IP SLA comes in. IP Service Level Agreements or IP SLA is a technology built into Cisco IOS that allows you to have the routers and switches deployed in your network. There are some great tools out there that allow you to easily leverage IP SLA - one being the SolarWinds IP SLA Monitor - which is free.


 


 


Another best practice is that you need to monitor and analyze your network traffic. Traffic monitoring can typically be done through an SNMP based application like the Network Performance Monitor within the Engineer's Toolset, the Orion Network Performance Monitor, or even an open source application like MRTG. What you're looking for is an applicatin that can easily monitor bandwidth usage on your pipes both in real-time and over time and makes it easy to see trends and analyze history.


 


 


For traffic analysis, while there are lots of ways you could go ranging from probes to protocol analyzers, IMO you can't beat NetFlow for what it gives you and how easy it is to start leveraging. I've talked a lot about this in the past both here on the blog and within our tech talks and webcasts so I won't get into a lot of detail - but it's hard to imagine how the idea of a feature available for free within the routers and switches you've already deployed into the network that can analyze who's using your bandwidth and for what doesn't look pretty darn good.


 


 


I could talk about this forever, but I know that I don't like reading really long blog entries and I'm going to assume that you don't either. Ping me sometime if you want more data and I'll expand on this topic within a webcast soon.


 


 


 


Flame on...
Josh


Follow me on Twitter

I was asked a question today about how Orion's Universal Device Poller (UnDP) works within a large, multi-poller environment. Usually I try to keep these blog entries somewhat product agnostic but this is a question I've been asked a lot and that a lot of you may encounter so I thought I'd spend a few minutes explaining.

First off, let's setup the environment. In the scenario we're talking about you've got a main Orion server and because of the number of devices that need to be managed you've also deployed two Orion Additional Polling Engines. As you know, Orion consists of several main components including the web UI (where most of your interfaction with Orion takes place), the SQL database (where the data is stored), and the "polling engine" which is a collection of processes and services that do the work of communicating with network devices to provide fault and performance management information.

Now, let's say that you've went out and bought some new WAN accellerators from company "BNHBGY" which stands for "Brand New and Hasn't Been Gobbled up Yet". These devices are brand spanking new on the market but are really cool so you've depoyed them all over your network (in areas managed by each of your 3 Orion servers mentioned above). You want to be able to measure how the devices are performing so you've decided to use Orion's UnDP to create custom pollers for them.

You would go to the main Orion server and create these custom pollers. From there, you can assign the poller to all of the devices of brand "BNHBGY". Orion will automagically figure out which Orion server (the Orion SLX Server or one of the two additional pollers) is managing the devices and handle things from there - no need to do anything on the additional polling engines.

For those of you that have been using Orion for a while this might be surprising as in the old days some of these things had to be done on the individual servers that were managing those devices. That's one of the cool new changes that Joel Dolisy (our Chief Architect) and all of the guys here on our engineering team have been working on.

Also, for those of you that are new to the process of creating and/or sharing UnDPs - keep in mind that the easiest way to do this is to go to the Content Exchange area on Thwack and download UnDPs that other users have created and shared. I very rarely have to create one myself anymore as so many users are contributing to Thwack nowadays.

Anyhow, that's it for today. I've been in the air all week and am about to board another plane. Hope you've all made plans to come see us at Cisco Networkers Live this year - it should be a blast.


Flame on...
Josh
Follow me on Twitter

Recently I've had a several people ask me for advice on getting started with managing their networks and so I thought I'd take a few minutes tonight to shed some light on the subject...

Now, this might seem like an odd topic as many of us have been neck deep in network management since we were knee-high to a grasshopper, but when you think about it we may have actually only been through the process of "getting started" a few times, once, or never at all. Often times we're brought in as part of an existing team where there's an ongoing network management strategy and so the early work has been done. Other times we may have been working at one place for so long that the concept of "getting started" is foreign to us (I've been working with SolarWinds since before our Y2K scanner was a big hit so I know about this first hand).

Thing is, there are lots of situations that may require you to start from scratch. For one, you may take over as the new network engineer or network manager at a company and realize that you're starting from zero. Could be that there's nothing in place or just that the stuff that's in place is such a cluster that it's just easier to start over. Another situation that might have you starting over is if the main person that holds the keys to these systems leaves the company and now you're dude responsible for making sure that stuff works. In either case, you'll need to grab the bull by the horns and start laying down a foundation that you can build on.

So, here's a quick Top 5 List for this head geek's take on how to get started with managing a new network... I'll expand this next week with 5 more to make it a Top 10.

#1 - Document the network. Whether you use LANsurveyor or some other application, you need to discover, map, and document your network. This is sort of like the "getting to know you" phase of a relationship. Every question that you don't ask now is likely to come back to haunt you later. Yeah, I've been there and trust me there are scarier things out there than undocumented internet connections or personal WAPs in your users' offices.

#2 - Learn about the primary technologies in use on your network. If you're a Cisco shop and you don't know much about Cisco technology then you need to find a bootcamp and go immerse yourself in the technology. If you've got things on your network that you've never heard of before, contact the hardware vendors and have the SE spend some time with you teaching you about the technology.

#3 - Find out who your key users are. Sometimes this might surprise you. Don't think of them as your most important users - think of them as the ones that are likely to do you the most damage.  This strategy seems to also hold up well in Halo, Gears of War, and God of War (BTW, I'm already planning my PTO for when God of War III releases so depending upon how hard it is to complete there may be a slight dip in new blog posts).

#4 - Document your applications. I was gonna call them "networked applications" but I couldn't think of any applications that don't rely on the network that anyone would want to document. If you've got a web application that runs on a VM that relies on a SQL Server that's 3 hops away on a secure VLAN that is accessed by partners through a VPN connection into yoru DMZ - see how this can get complicated? Generally speaking, users don't complain about network issues - they complain about applications. You'll hear that "e-mail is running slow" or "the internet is down" way more times than you'll hear that you've got a spanning-tree problem between the LDF switches on the third floor.

#5 - Get a network management system in place. Pick something that you can download, install, and have up and running quicker than you can watch last week's American Idol (even if you are fast forwarding through the commercials and most of the singers and just to hear the crazy things that Simon, Paula, Randy, and that hot new chick say).

So, there's my top 5. Ping me back if you agree, disagree, or you want to debate Adam Lambert's rendition of Ring of Fire.


Flame on...
Josh
Follow me on Twitter 

This morning I had the opportunity to participate in a podcast with my buddies and the co-hosts of Cisco's TechWiseTV Jimmy Ray Pursor and Robb Boyd. The subject was the Conficker threat and I must say that I learned a few things as Jimmy Ray really knows his bots. We also talked about the best ways to avoid bots, the difference between bots and viruses, and some recommendations for protection software.

It was a heckuva lot of fun and definitely provided some good informaiton. You can use these links listen to or download the podcast.


Flame on...
Josh
Follow me on Twitter

Filter Blog

By date: By tag: