Skip navigation

Well, I'm fresh back from a short vacation down in Argentina and I find myself working on a problem today that required the use of a protocol analyzer or "sniffer". It got me to thinking about the fact that many network administrator's today have never actually taken a packet trace or analyzed a packet. Furthermore, when the need does arise, many of the people I deal with don't really know how to get started.

So, with that in mind, here are few things to keep in mind if you find yourself in that situation...

Head Geek's Top 5 Things to Remember about Analyzing Packets

#5 - Don't assume that the answer is in the packet. Remember the top 3 network troubleshooting steps - check the cable, check the cable, check the cable.

#4 - If you're going to go looking at packets, use Wireshark. You can download it for free from wireshark.org. It's the best protocol analyzer out there - period.

#3 - Remember that with today's ethernet switches you have to mirror (span) the data from the port that you want to monitor to the port where your analyzer is connected. A few of us old timers keep a spare 4 port ethernet hub laying around for cases where reconfiguring the switch isn't convenient...

#2 -  User capture and view filters to limit the number of packets that you have to look at. For instance, if you're troubleshooting a website performance issue you can probably filter everything out that's not to/from the client machine and the webserver and everthing that's not to/from TCP port 80.

#1 - Combine the data that you get from looking at the individual packets with the data that you get from investigating packet flows leveraging a technology like NetFlow. If you don't have a Netflow appplication, you can download a free evaluation version of the SolarWinds Engineer's Toolset and Orion NetFlow Traffic Analyzer from the SolarWinds website. The evaluation versions are fully functional and work for 30 days.

Packet sniffing isn't for the faint of heart but I've solved some problems that were real buggers with this method. If you've got some cool stories of issues you've solved after investigating the packets post a comment here and I'll send you a SolarWinds T-shirt.


Flame on...
Josh

Josh Stephens

Switch Port mapping

Posted by Josh Stephens Jul 24, 2008

 Hey guys, check out this new video where I provide some quick tips on mapping switch ports. 

 

I am on my way to Argentina for a quick vacation so have a great week.  Flame on!!

SQL Server performance is a hot topic these days, especially if you're leveraging your SQL Server for a high performance NMS. This can become even more critical when you add applications like NetFlow which tend to carry a significant I/O burden.

In some organizations you can rely on the DBA team to own/maintain/optimize the database servers for you. Unfortunaely, for many of us this isn't an option either because we dont' have a DBA team or because it's such a political mess trying to work with them. This causes us to have to implement and maintain our own database servers to support our apps.

The thing is, most of us network engineers don't know diddly about database servers. So, with that in mind, here are a few tips for optimizing your SQL Server:

Head Geek's Top 5 Tips for Improving SQL Performance

#5 - Add more RAM. Doesn't really matter how much you have, adding more will almost always help. Be sure that your SQL instance and OS are capable of consuming the additional RAM and if not make it so.

#4 -  Just say "no" to RAID 5. It's great for application servers but horrible for database servers where I/O performance is important.

#3 - Place the data and log files (.mdf and .ldf) on separate logical drives and separate channels or controllers.

#2 - Unless your SAN is optimized for high I/O vs. large I/O stick with a locally attached disk arrary.

#1 - Buy disk controllers with battery backed-up write-back cache. The more the better, but at least 256MB.


Flame on...
Josh

I've been doing network engineering ever since I was knee high to a grasshopper and I'm still just as guilty as the next guy - when I see a problem the first thing I do is blame the network. Case in point, I was hosting a webcast for some of our partners today and during the presentation the demo server that I was using suddenly started timing out. My first thought - we have a performance issue on the network. Before I could stop myself I'm reviewing NetFlow statistics, running TraceRoute utilities, and trying to figure out where the bottleneck was occurring....

Actual problem - one of the applications that the demo server uses crashed and needed to be restarted. Sure, our IT departments Orion and ipMonitor servers caught this and stared sending out alerts , but I was using the application at the instant that it crashed so I was literally the first to know.

My point here is that if you don't have a good set of network management tools in place to tell you where to place the blame when issues like this occur you're asking for trouble. When the boss's secretary starts blaming you for the fact his e-mail is slow or the new exec is complaining because her favorite YouTube videos are all jittery, you need to have a better answer than "it probably isn't the network." A few years ago there were a lot of pretty good excuses for flying blind and going without network management:

  • The solutions available were way too complicated to setup and maintain
  • The products dominating the market were incredibly overpriced
  • The "leading" vendors in space didn't really understand your perspective as a network engineer

Fortunately, the landscape has changed and these things are no longer true. Sure, the old-style products from the old-school vendors still exist but there's a lot of really cool new stuff out there from people that actually understand what you're going through.


Flame on...
Josh

p.s. In case it wasn't crazy obvious, we're one of the companies offering this new-breed of network management products. Download them yourself at http://www.solarwinds.com

I get asked a lot about monitoring "custom" attributes with Orion and while this was definitely possible in Orion v8.x it's dramatically improved in Orion 9.x with the new "Universal Device Poller" or "UnDP".

The UnDP is one of the new features of Orion v9 which released on July 1st of 2008 (about 2 weeks ago). It not only allows you to pull basic data stored within propietary MIBs but also allows you to do some pretty advanced monitoring like pulling in entire tables and running calculations against the collected data.

I've had great success thus far with using the UnDP to collect statistics on static and dynamic VPN tunnels, virtual servers and the hosting infrastructure, fiber switches, multi-battery UPSs, and environmental stats on my Cisco gear.

Anyhow, give it a try and let me know if you think of some cool stuff to use it for.


Flame on...
Josh

This week I had the opportunity to discuss some network troubleshooting tips with Chris Pirillo at Lockergnome.  If you're interested, you can watch the segment on YouTube.com by visiting:

http://www.youtube.com/watch?v=zVjuRBL9s9Q

Thanks,
Josh

We're hosting a free webcast on network management architectures - distributed vs. centralized - this Thursday. Go here to sign up or learn more:

http://www.solarwinds.com/register/index.aspx?Program=847&c=70150000000Dmwh

Flame on...
Josh

If you haven't seen this video, it's pretty darn funny...

http://www.solarwinds.com/orion/index.aspx?DCMP=OTC-TWIT-Orion-Gameshow

Josh

p.s. Happy Independence Day and I hope you all have a Safe and Happy Holiday Weekend.

Josh Stephens

TFTP FAQs...

Posted by Josh Stephens Jul 2, 2008

Last week at Cisco's Networkers Live we answered a lot of questions about the SolarWinds TFTP Server and TFTP (Trivial File Transfer Protocol) in general so I thought I'd take a few moments to share some of the most common questions and answers.

q)  Does the SolarWinds TFTP Server still have a 32MB file size limitation?
a)  No. The SolarWinds TFTP Server now has a 4GB file size limit.

q)  Why did the 32MB file size limitation exist?
a)  The original RFC for TFTP used a fixed block size, which inherently limited the file size to 32MB. RFC2347 and RFC2348 introduced and allowed for block size negotiation which allow for file sizes up to 4GB or larger if the server and client support block size wraparound.

q)  Why is it that even though I'm using the latest SolarWinds TFTP Server I can't transfer files larger than 32MB?
a)  Remember, both the client and the server have to support block size negotiation. So, if you're running the SolarWinds TFTP Server on an XP Workstation and transferring a file to a Cisco router with resent IOS it'll work great. However, if you're running the TFTP Server on an XP Workstation and transferring the file to another XP Workstation using the standard XP TFTP client you'll be limited to 32MB as this is the maximum that the standard XP client supports.

q)  Can I run the SolarWinds TFTP Server on the same server with Orion NPM, Cirrus, or other SolarWinds products?
a)  Yes, no worries.

Anyhow, I use the TFTP server at least a few times per week so I wanted to be sure to pass this information along...

Flame on...
Josh

p.s. before he flames me, thanks to Greg Newman our Toolset lead developer and architect for providing some of the information above :)

Filter Blog

By date: By tag: