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.
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 :)
Hello out there. I'm out in sunny Orlando Florida at Cisco Networkers Live this week. Come by the booth and see us if you're out in this neck of the woods...
It never ceases to amaze me when I talk to companies that run large networks and don't even have the most basic of configuration management systems in place. I talked with some guys today that run a network with over 100,000 routers, switches, and firewalls and do all of their config changes by hand and don't have an easy way of backing up the device configs. I've been there - and it's a scary way to live...
I think the reason for this is that so many of us have had horrible experiences with traditional configuration management solutions and we'd rather live with the fear of doing nothing than live with the nightmare that these systems can become. Look at this way - the number of companies that don't leverage a configuration management application is high. The number of companies that have never purchased a configuration management solution is low. Therefore, there are a lot of companies that have spent money on configuration management solutions and then decided it was easier to stop using them.
I normally don't push product in this blog, but ff you're in this position you really need to take another look at some of the products out on the market today. While my opinion isn't exactly neutral, my obvious favorite is the Cirrus Configuration Manager that we offer here at SolarWinds. You can download a free evaluation copy from our website and try it for yourself. There are some pretty good open source tools out there as well, but for the money Cirrus is well worth the investment for what you'll save in time implementing an open source app.
A few minutes ago I was walking through the office checking on things and answering questions when some of the guys stopped me to ask why the "internet" was running so slow. My first reaction was to explain that the internet was actually running quite normally but that our connection to the internet seemed to be experiencing higher than average latency. However, as I looked over the shoulders of the guys asking me I noticed that each one of them had a window open trying to watch streaming video from the U.S. Open and I realized that any explanation I could give would be futile.
One of the challenges that we face today is that our users are used to having much more bandwidth at home than most of us can provide here at the office. Take me for instance. I have a 15 Mbps connection at home pretty much all to myself. If I'm really feeling hoggish I can load balance between my cable connection and my neighbor's DSL and get even better speeds. But here at work I'm sharing the same corporate connection with everyone else and so sometimes it feels slow even though I'm technical enough to understand the reasons why.
I have seen a few companies that plan for events like the U.S. Open and stream the video locally and then let everyone watch the same feed. While expensive initially, in the long run these systems can really work wonders towards network performance and employee perception of network availability.
I'd love to hear your thoughts on the subject and Congratulations Tiger on a game well played.
On Thursday we're hosting a webcast on "How Network Management Systems Work. We'll cover technologies including SNMP, WMI, SSH, MIBs, Syslog, Traps, and more. To sign up visit:
http://www.solarwinds.com/register/index.aspx?Program=823&c=70150000000DhqJ&CMP=ILC-ILC-GeekPg_HNW_Webc
We'll also be doing some giveaways and of course it'll be recorded and posted to the website for anyone that misses the live event.
Recently we added support for NetFlow Version 9 to the Orion NetFlow Traffic Analyzer. Since then, I've helped several customers configure their devices to correctly send NetfFlow v9 data and based upon some of the questions I'm seeing in our forums and elsewhere I figure'd it would be a good topic to write about tonight.
The single most distinguising factor of Netflow v9 (which later became the basis for the IETF standard and for IPFix) is that it is template-based. In NetFlow v5, you have a fixed set of fields and the format and order of these fields are known by both the sender (the router) and receiver (Orion NPM for instance) and are fixed. With NetFlow v9 (and IPFix), the sender sends periodically sends a template that tells the receiver how to interpret the data that's being included in the NetFlow packets. There are several advantages to this technology - one of which is it allows both the hardware vendors supporting NetFlow and the software vendors (like us) receiving and displaying NetFlow data to support new technologies very quickly.
For now, the number one thing to remember is that when you're configuring the network device (router, switch, firewall, WAN optimizer, etc) to export NetFlow v9 packets you MUST specify the template that will be used for the packets. This is an additional command from what you may be used to when configuring for NetFlow v5 or SFlow.
As you may have read in a previous post, SolarWinds has been working on a new free tool for monitoring Microsoft Exchange Servers. As you know, a big part of our culture here at SolarWinds has always involved supporting and contributing to the community and providing cool free software is an important part of how we do that.
Well, the new free tool isn't officially available yet but we've decided to give it to our loyal community members a bit early. You can download from:
http://www.solarwinds.com/register/index.aspx?Program=825&c=70150000000Djc6
Enjoy and be sure to let us know if you have any feedback or suggestions for this free tool or others that you'd like to see.
For many of us, especially those of us managing firewalls, the volume of syslog messages that we receive on a daily basis can be overwhelming - especially for the systems that we have receiving, analyzing, and storing them.
Orion NPM includes a great Syslog Server - we've it tested under loads of several thousands of messages per second without issue - but if you're receiving 10,000 syslog messages every minute and you're keeping 30 days worth of history do you really need 432,000,000 syslog messages eating up resources on your database server?
One of the features that many of our diehard Syslog users swear by is the rules/alert engine built within the Syslog server. Many people use this to detect and be alerted on security threats, malicious use of resources, and etc - but not too many people know that you can also use it to automatically filter the syslog messages before they get written to your database to keep your database size in check.
To do this, simply open the Syslog Viewer and choose "File", "Settings" and then go to the "Alerts/Filter Rules" tab. Once there, build a new rule to discard the unwanted messages before they're written to the database. You can filter it so that some of the messages that you really don't care about anyway are automatically dropped - saving lots of space on your SQL server and making the important messages much easier to store, review, and search.
Anyways, hope this helps and ping me if you have any questions on this.
Up until now I've been sworn to secrecy, but it looks like they're finally going to let me talk about this...
SolarWinds is just about to release a new free tool for monitoring Microsoft Exchange Servers. For those of us that have had the, well, ummm, "privilege" of managing and monitoring Exchange servers we know what a pain it can be and how crazy our users get (especially the executives) whenever there's a problem with the e-mail server.
This new free network monitoring software can track things like:
The new free Exchange Monitor will be available soon from SolarWinds.com.
As always, ping me if you have questions or suggestions around this new free software.
Here lately I've been asked alot about using Orion to collect data for PCI compliance. For the most part, this is pretty easy as Orion does a great job of managing routers, switches, firewalls, and servers. As a matter of fact, I've helped hundreds of customers setup special reports in Orion to highlight these features.
Things get a little more complicated when it comes to collecting logs from Windows servers and PCs. One way to tackle this is to use the Windows Event Log forwarder that we provide as a free download. This utility installs on the Windows systems and converts the event log messages into syslog messages and forwards them to Orion's Syslog Server.
Another creative way of solving this problem is to use the SNMP trap service on the windows machines forward the event log messages as traps. Orion can then receive, store, and alert on these traps.
Orion includes a highly scalable rules engine for the SNMP Trap Receiver and the Syslog Server that can be used to setup alerts and actions based upon message format, content, source, and etc. The users that take advantage of these features love them - but not too many people know about them.
Obviously, there are many other ways to collect this data including collecting it directly via WMI and using other third party agents to provide the logs. I'd love to hear how you're collecting logs from your Windows systems and any hiccups that you've encountered.
Well, I'm out in New Jersey this week talking with the DoD about network management systems, interoperability, and best practices for building NOCs. I'd planned to take my iPhone out and get some cool pics of me standing in front of a tank or something but it's been dark when we finish every day.
It's interesting to hear everyone's opinion about how network management systems should operate and interoperate. Definitely some very smart people here and I'm looking forward to chatting with them more tomorrow.
In the meantime, I've been thinking a bit about how these practices can apply to those of you in the commercial sector. If you've got a cool NOC drop me a note and I'd like to chat and possibly come see you.
Two of the things that I get asked about a lot are a) how often you should poll your devices and b) how SNMP counters work. Let's address the question about polling frequency first.
There are two primary types of polling - polling for status (up/down/warning) and polling for statistics (latency, traffic, errors, CPU, memory, etc). There are many schools of thought on how often you need to poll for status. On the extreme I've worked wiht customers that want everything from "once per day" to "real-time or every second". Across the industry 5 minute polling for status is pretty standard, while some products like Orion use a default of 2 minutes. When thinking about how often you need to poll for status there are few things you should know. First, a strong fault management strategy will include both status polling and monitoring for SNMP traps. Status polling gives you a guaranteed way of finding outages but doesn't happen in real-time. Traps happen in real-time but you have no guarantee of receiving the trap. By leveraging both technologies together you gain both speed and accuracy. Second, you need to understand that there are different types of status polling. Most polling for device status is done via ICMP (ping). Status for interfaces, CPUs, volumes, and other sub-elements are ususally done via SNMP and status checking for applications may use SNMP, WMI, or the actual application protocol.
Polling for statistics is a little different. The first thing that you should know is that most of this type of data is stored within two MIB types - gauge and counter. If you're polling a stat this is stored within a gauge, then you need to know what the gauge represents. For instance, most Cisco devices support three different MIBs for CPU load - real-time, 1 minute avg, and 5 minute avg. So, if you're polling every 2 minutes stick to the 1 minute average but if you're polling every 9 minutes go with the 5 minute average. Mature products like Orion figure this stuff out for you, but you can also manually force the behavior so that you can experience he different results. The other common type of MIB used for polling statistics is a counter. Using an SNMP counter to calculate a rate is much like using the odometer in your car to calculate gas mileage. For instance, if your tank is full and you drive 100 miles and then can add 10 more gallons to the tank to get it back to full then you've gotten 10 miles to the gallon (not uncommon in a diesel guzzling 4x4 behemoth like I drive). An example using SNMP counters would be the MIB used to measure traffic on a network interface. The MIB will show you a running total number of the octets (bytes) of traffic that have went in/out of the interface. So, if you poll the MIB and find out that it's sent 1000 octets and then poll it again in 10 minutes to find that it's now sent 10,000 octets you know that in 10 minutes it sent 9,000 octets which correlates to 120 bps. ((9000*8)/(10*60))=120. Generally speaking most people poll these status every 15 minutes, but poll critical connections every 1-2 minutes. Orion pulls this data every 9 minutes by default. Just like how it's important to use status polling along with SNMP traps, it's important to use a technology like NetFlow along with polling for traffic rates.
Anyhow, that's a really brief introduction to this subject. Ping me if you have questions.
The marketing team here is hosting a survey and giving away some pretty sweet prizes. Well, I would never actually purchase a Wii myself, but if I won one I'd sure as heck play it :)
Here's a link to the details. Help us out and take a few minutes to fill it out...
Take a few minutes to share your thoughts in this short online survey. Why, you ask? Well, it's a great opportunity to have your voice heard back at SolarWinds HQ, plus we'll be giving away a Nintendo® Wii® to TWO lucky respondents, so start those mouse buttons clicking!
TAKE THE SURVEY
Well, I'm home now and had a great trip out to Virginia. I got to meet with several customers and some people that are interested in becoming customers so it was a great trip.
For those of you that responded but I was unable to visit this time, I'll be headed out that way again soon.