I'm flying out to Baltimore tomorrow and driving down to Virginia for a meeting Tuesday morning. I think I'll have a couple of extra hours on Tuesday afternoon and would love to go see one of our community members. Ping me on the blog or via e-mail to make contact...
Flame on...Josh
I get asked a lot about using Orion (which requires SQL as a database backend) with a SAN. This usually comes up when people are also leveraging the Orion NetFlow Traffic Analyzer (NTA) which can cause the database to grow very, very quickly.
Before I get started, let me say that I believe that the product documentation and the official stance of our tech support team is that we don't recommend running Orion w/NTA with a SAN, and for good reason based upon our overall experience in this area. You see, SANs are great for moving and storing very large amounts of data. In many cases you can actually read and write data more quickly to a high-performance SAN than to locally attached disk. The problem is that with applications like Orion you're not moving large chunks of data; instead, you're moving ginormous amounts of itty bitty pieces of data and most SANs just don't have the ability to handle this number of I/O transactions in the timeframes that applications like this demand. Time and time again we've seen issues where data is getting dropped when trying to write to a high-performance SAN but after moving the data to even a moderately performing local disk array the problem goes away.
For example, I worked with a customer recently that was seeing holes within some of the data sets the he was collecting and was leveraging a SAN to house his SQL database. Additionally, when trying to query the database for these results the queries would sometime time out. We turned on some perfmon counters on the SQL server and we were seeing disk queue lengths (read and write) of 200-300. Microsoft recommends that for SQL Servers with high amounts of I/O the disk queue lengths not exceed twice the number of physical disks (which in this case was 13 if I remember correctly). After moving the database to a local disk array (RAID 1+0), the problems went way...
What inspired me to write this post is that last week while I was at InterOP I had a chance to meet with several of the SAN vendors and to review some of their newer technology and it seems like maybe SANs have now evolved to a place where they could be used very effectively in these scenarios and may even out perform local high-speed arrays. I'll have to wait to see, but it definitely seemed promising.
If any of you out there are effectively utilizing SANs in environments please drop a comment with some specifics.
A recent post on the forum for the Orion Network Performance Monitor (NPM) at:
http://thwack.com/forums/p/8407/35095.aspx#35095
got me to thinking about some cool customizations that I've seen implemented on Orion and also a few best practices for using the Orion web interface. Orion's going to be turning 7 years old this year and the website has come a long way and I've seen some really, really creative customizations. Some of the most useful things I've seen have been in the areas of maps and reports. You can create some really complex and interesting maps and reports within Orion. I've seen maps with literally hundreds of levels and containing tens of thousands of elements. As for reports, one of the coolest is the one that Savell from down under posted at:
http://thwack.com/files/folders/orion_custom_reports/entry28320.aspx
There are also some things that you can do to the Orion website that require virtually no effort but can offer huge payback. Here's my Top 5 list of Must Do's for Orion NPM website customization:
Head Geek's Top 5 Must Do's for Orion Web Customizations
5. Don't use the "Network Wide" charts and/or resources on any commonly viewed pages. These resources do exactly what they sound like they do, and therefore are can take as long to run as several of the other resources combined. Save these resources for where you really need them (if you need them at all).
4. Right-size the views for the screens that you commonly use. If you have Orion displayed in your NOC on a large HDTV like many customer do, you probably have room for at least 4 columns on the screen.
3. Put your company logo at the top of the page. Your boss will love it and his boss will like it even more.
2. Leverage the 'Views by device type" feature. If you're looking at a Node Details view for a router you want to see CPU, memory, buffers, NetFlow stats, and possibly VoIP call paths. But, if you're looking at the Node Details page for an APC UPS you want to see battery life, power input/output values, and etc.
1. Build views that include data from all of the components - Orion NPM, NetFlow, APM, VoIP, and Wireless. This is the absolute, number one thing that you can do to make your Orion views more usable and to cut down MTTR for issues.
If you're interested in hearing more about cool things you can do to the Orion web console respond here or send me a note (headgeek@solarwinds.com) and we'll schedule an informal webcast with an open Q&A and hit it in more detail.
Josh StephensHead Geek, SolarWindshttp://www.solarwinds.commailto:headgeek@solarwinds.com512.682.9357 office
Well, the first day of InterOp 2008 is behind us and what a day it was. A few thousand of you came by the booth today for free software, t-shirts, and to learn more about our software. Heck, we even had free beer from 3:00 to 5:00 when the show closed!!!
If you're in Vegas this week stop by and see us and I'll hook you up with some goodies. Hope to see you here...
p.s. A new version of our NetFlow Traffic Analyzer released yesterday and includes several key features including support for sFlow, J-Flow, and NetFlow v9. Additionally, we made several enhancements to the web UI and added a custom, ad-hoc reporting engine that makes it really easy to drill down to the specific data that you're looking for. You can check it out at SolarWinds.com and we'll be doing a webcast to go over all of the new features soon.
I've been involved in a lot of conversations recently both here internally at SolarWinds and within the community regarding whose responsible for monitoring what. Are the networking folks responsible for monitoring server hardware? Are the systems folks responsible for monitoring virtual switches? Does the NOC do application level monitoring?
In most cases, the answer to all of the above questions is 'YES'. As a matter of fact, in most organizations there is a lot of monitoring overlap - even if there is a dedicated group for monitoring. Most networking shops want to at least monitor the server infrastructure, server ports on the switches, and layer 4 connectivity to applications. Most systems shops want to monitor available bandwidth, relevant network paths, and virtual switching infrastructure. Then of course you have the monitoring and/or NOC teams that need to monitor everything and we haven't even talked about the security folks...
Another way to look at it would be to focus on the monitoring technology/data. Let's say for instance that you're using Orion and the APM, NetFlow, and VoIP modules. While the perspectives and therefore reporting needs are different, in most cases all of the groups above want access to information collected via NetFlow, information on system and network performance, application availability, VoIP calls stats, and etc.
I'd like to hear from you on what you're responsible for (network, systems, monitoring, security) and where you draw the demarc in terms of what you want to have visibility in to from a monitoring perspective.
Thanks and hope ya'll have a great weekend.
Josh
I'll be in Vegas for InterOP next week. Stop by our booth and chat if you have some time...
A couple of weeks ago we hosted a webcast on cost saving techniques for managing networks. It went great and we had several hundred people attend the live event and lots and lots more have viewed the recorded version at
http://www.solarwinds.com/register/index.aspx?Program=811&c=70150000000DZAL
All that said, it didn't quite reach the level of geekiness that I like to put into webcasts. So, I've decided to raise the geek factor for this next event and do a deep dive on flow based technologies including NetFlow, JFlow, SFlow, and IPFix and I've invited our Chief Architect Joel Dolisy to cohost.
Sign-up information will be place on SolarWinds.Com and here on the blog within the next day or so. If you've got specific questions about this technology that you'd like to see answered drop me comment. Current agenda is to cover:
• The basics of traffic flow technologies• The Top 5 Reasons to use them• Possible downfalls – Rumors and Facts • Comparisons of NetFlow, JFlow, SFlow, and IPFix• Deeper analysis of each traffic flow type• Technologies that receive and analyze flow data
For those of you that haven't seen it, the new Incredible Hulk movie looks freaking awesome. I guess maybe it comes with the territory when you're as geeky as I am but I absolutely love superhero movies. I've probably watched the trailers for this and the new Batman movie a hundred times each...
Of course, in doing so I'm chewing up precious bandwidth and probably causing some of our executives to wonder why their VoIP calls to our other offices are so jittery, but hey, how often does a new Incredible Hulk movie trailer get released? And seriously, our QoS deployment should protect against this - or at least, protect against normal users doing this :)
Anyways, I digress. As you know, one of the cool things that you can do with NetFlow is to measure how much of your network traffic is actually people like me geeking out on superhero movie trailers. I had a situation last week where a company was using Orion and our NetFlow module and they weren't seeing the data that they thought they'd be seeing. Long story short, they were trying to watch the traffic in and out of the ports on one of their core switches. It was a Cisco Catalyst 4503 running IOS and all of the ports were a part of the same VLAN. Most of the traffic never left the subnet - meaning it was all switched traffic. Now, my understanding of NetFlow was that you're only able to see traffic that crosses layer 3 boundaries - i.e. interVLAN or routed traffic. This was also the opinion of the engineer at the Cisco TAC that the comany had been working with so my first reaction had me ready to say that it wasn't possible and move on to the next case.
The company wasn't pleased with this information and really needed the layer 2 traffic detail and I got the impression that I "wouldn't like them when they're angry" so I started digging deeper. I am fortunate enough to know a few of the product managers at Cisco including the PM over NetFlow so I called in a favor to find out if there was any way to do this. I learned several things...
First, on the 4503 running IOS version 12.2(40)SG or later this IS POSSIBLE!!! There are some new commands that I'd never even heard of. Specifically:
ip flow ingress (which we've all probably used before and enables the routed flows)
ip flow ingresslayer2-switched (whoa there hoss - this was totally new to me)
ip flow ingress infer-fields
Once turning on these commands sure enough we started seeing the layer 2 switched traffic via NetFlow. This is totally cool. I was hoping to see it allocated to the port that it went in/out of, but you can get around this by viewing it by either the connected device or using an address group for the connected devices in the case of a downstream switch. Secondly, I also saw that some of the traffic was associcated with the EOBC interface. I'll send a SolarWinds shirt to the first person that adds a comment explaining what this is - and yes I know what it is so I will be verifying the answers :)
Anyhow, I thought this was definitely worth sharing. If you've got any experience with using NetFlow to monitor layer 2 traffic shout it out to the group...
I was answering a set of e-mails today on when's a good time to change network management products, what trends I'm seeing in the industry, and how to evaluate a network management solution and I got to thinking that these are some of the questions that we answered on our recent video segment with Gartner Group. So, if you're interested you can watch the segment at:
www.solarwinds.com/garner_video/
No promises on how many times I stutterred or said "uhhh" or "ummm" but in my defense it was hot as heck in that room... Not the geekiest comments I've utterred but definitely some value there.
Recently I worked with a magazine editor who was evaluating and writing about some of the new 802.11n WAPs out in the market. These particular WAPs were aimed at the small business and home office. The testing went well and I think it was a good contest and should make for a great article.
While this type of testing is helpful, as I was working from home this weekend over my 802.11 network I was thinking that what we really need is a test that is designed to catch the issues that typically tick off users like me. Lab tests typically involve testing for throughput, evaluating the installation/configuration experience, and evaluating against a list of desired features. But when asked "What Would the Geek Do" with regards to testing these devices, my preference would be to run each of them for a week or two in production and see how they hold up and compare them against the user experience when using the older WAPs to see if they offer a real, tangible improvement. The Top 5 Things that I look for in a WAP are:
1. Reliability - once I configure it and get it up and running, I don't want to have to screw around with it again. It should just work from that point on. It's freaking ridiculous for me to have to walk my wife (or any non-technical user) through resetting the WAP when it's decided to stop working and I'm on the road.
2. Performance (Throughput) - not only for wired to wireless speeds but also for wireless to wireless connections. Additionally, how is wired to wireless speed affected when you have 3 or more devices downloading simultaneously?
3. Performance (Scalability) - sure it works with 1-2 laptops connected but what happens when I add 5-6 additional laptops, a handful of iPhones, and a couple of AppleTVs? If I'm in the middle of a 4GB download and someone turns on a cordless phone, microwave, or etc am I going to have to start over?
4. Range - I don't have a huge house so I should be able to get good wireless signal anywhere in the house. Nothing hacks me off like not being able to surf from bed because of a lousy signal. Sure, there's a rack full of test gear sitting near the WAP but that's no excuse for poor performance.
5. Security and Manageablity - This is a no-brainer and it's non-negotiable. The teenagers in my neighborhood are relentless (my son is one of them and is almost as good at hacking into networks as I am). With regards to manageability, it needs to support basic SNMP monitoring so I can at least monitor throughput and device performance.
So, I'm going to do this. If you are a hardware vendor or reseller and want your devices included in this test then drop me a line at headgeek@solarwinds.com and I'll send you the shipping information. Otherwise, I'm going to go buy a handful of what I think are representative models and see if I can find a winner or two...
When last I wrote on this subject, I was in Cork Ireland and I'd just switched from a Windows Mobile device that I used as a phone and PDA to a new Blackberry Curve. I will admit that my opinion of the Curve was somewhat hasty. I used it for about a month and after learning several of the shortcuts and best practices that diehard Blackberry users leverage it was definitely more usable than I first thought. I can't honestly say that the UI was really all that much worse than on the Windows Mobile. The real difference is that I'm used to the Windows UI so I was already trained in its advantages and disadvantages. At the end of the day, these were the three largest issues that I had with the Blackberry. First, the Exchange sync isn't very good, even with our corporate REM server in the mix. After spending the day working from my laptop and wrangling through hundreds of messages in my Inbox the last thing I want to see is that the messages I'd removed my my Inbox are still there on the Blackberry. Second, the web browser is very weak. Going from the FireFox v3 beta on my laptop to that thing was depressing. Third, the multimedia capabilities aren't mature yet and I found myself still carrying my iPod everywhere I went.
So, it just so happened that my wife had started swiping my iPod Nano and so I picked up an iPod Touch. It only took me about 20 minutes to decide that it was the coolest thing since variable length subnet masking and so I returned it and upgraded to an iPhone.
Thus far, I freaking love it. I spend more time at home on my iPhone utilizing my WiFi network than I do on my laptop. The UI is fantastic - virtually no learning curve and a few features that just make you say "wow". I'm an iTunes fanatic so the fact that I can skip the laptop and go straight there from the iPhone is awesome. No more carrying a phone, PDA, and/or iPod. This is truly an all-in-one device.
The real test will come the next time I have to travel and rely heavily on the PDA functions of the phone for e-mail, viewing documents, and etc. Here at home it seems pretty good, but this isn't a fair test for those features and certainly doesn't compare to being stuck in Heathrow for several hours with nothing but a Blackberry and a ton of work to do.
I never thought I'd say this, but my experience with Apple products has been so good the last couple of years that I'll probably replace my laptop with a MAC. I know - what the heck am I saying - but, wow this phone is cool. I'm also in the midst of ordering an AppleTV for the house which I'm hoping will turn my HDTV into a giant iPod.
More to come in the next few weeks as I have some trips coming up that should push this thing pretty hard. BTW, if you're out at InterOP this year come and see me and I'll hook you up with some free stuff. If the phone proves to be a bad travel companion for work my teenager will inherit it and I'll go back to the iPod Touch for my music and video needs and try one of the next generation Windows Mobile devices next.
So I got a chance to catch up on some basketball this weekend and then this morning we were all chatting about the NCAA tournament and a friend of mine told me that her husband wasn't going to shave until the Jayhawks won the tournament. Several years ago I lived in Kansas City and helped to design and deploy the network that is now Sprint PCS. One thing I learned while I was there - those people are passionate about their basketball...
Anyhow, that got me to thinking about the lengths to which people will go when they are passionate about something and since I'm passionate about Orion and I know that some of you are too I thought I'd write the "Sweet 16 Ways to Optimize your Orion Installation". Yeah, this would've been easier to do once we get down to the Elite 8 or Final 4, but those who put off until tomorrow...
Sweet Sixteen Best Ways To Optimize Your Orion Installation
16. Use the new, updated AJAX version of the All Nodes resource (and others) on your Orion web views to enhance performance.
15. Move away from RAID 5 for your SQL disk array. Stick with RAID 1+0 or some other RAID that offers higher disk I/O performance.
14. Disable any unused services on your Orion server. This includes any services that might've been installed by Orion but that you're not using (Traps or Syslog for instance) and especially any unused instances of SQL.
13. Separate Orion and SQL Server onto separate machines. Sooner or later you're going to have to do this anyway...
12. Don't use System Manager. Yes, run the System Manager to add devices, make config changes, and etc - but when you're finished shut it down (gracefully) and use the website for viewing the data. System Manager is intended to be used for administrative purposes...
11. If redundancy and fault tolerance are a concern, buy a copy of the Orion Hot Standby Engine.
10. ICMP Packet Payload - by default, Orion includes data within the payload portion of the ICMP packets that it sends for checking node status, availability, and latency. In many cases, you can improve performance by removing this data (go to "Settings", "Network"). Caution - in some cases, network devices (especially firewalls) will block ICMP packets an empty payload. Use this power carefully young ones...
9. Polling intervals - trust me, you don't need to poll as often as you think you do. Most people poll for status every 5 minutes and collect statistics every 15. Orion's default values are 2 and 9. If you do need to poll some devices more often, divide your devices into groups for "normal" and "critical" and then manage only the critical devices with the tighter interval.
8. Remove unused web resources from your Orion views. You know, those resources that you never really look at anyway - they're slowing down your website and eating into SQL resources.
7. Use the Orion website for viewing data and only use the System Manager when doing administrative tasks. Yes, this is a duplicate of number 12. I will give a free shirt to the first 5 people that catch this and comment about it. Send me your shirt size and etc via e-mail after commenting on the blog.
6. Tune your polling engine. Do this with the "Polling Engine Tuner" or just do the math and update the registry yourself. Either way, do it.
5. Add Orion polling engines. If you're polling more than about 10,000 elements on your Orion server or 1500 elements per minute consider this.
4. If following number 5 and adding polling engines consider deploying them on virtual servers vs. physical ones. This can save both time and money.
3. Do daily database backups. I shouldn't even have to tell you this but some of you (and you know who you are) don't think this is important. Trust me, at some point that Windows server is going to burp and you're gonna wish you'd listened...
2. Get a copy of Orion for you lab. Deploy and test new versions, significant configuration changes, and etc in the lab before you deploy them into production. In case you haven't noticed, I'm big on labs...
1. Use the Orion Modules - this is an inexpensive and easy way to expand your Orion implementation and add new features such as NetFlow, application monitoring, and VoIP network analysis.
Some of these tips were contributed by Denny (Orion's Product Manager and all around cool guy), Dan (Orion guru and shotgun aficionado), and Destiny (Orion expert and part time ninja).
A subject that I get asked about a lot is how to monitor and measure network traffic. There are many different ways to look at network traffic and link performance and several different schools of thought on which measures hold the most value.
In discussing this subject, let's first limit the conversation to WAN link analysis which is usually where people start to see issues with bandwidth utilization and latency. This isn't to say that you can't see these issues on the LAN - just the other day I was talking to an engineer that is daily fighting these issues on his LAN where the amount of data, voice, and video traffic is overwhelming even 10 gbps links in cases. Nevertheless, much more commonly the issue is on the WAN so let's talk about that first.
The first thing to understand about WAN links is that they're pretty much all full duplex. This basically means that they can both send and receive traffic simultaneously. You might compare a full duplex link to a typical highway bridge and then contrast that with a half duplex link which is more like one of those old time wooden bridges that is only wide enough for one car. This is important because you now have to analyze the traffic in each direction, almost as if they were two separate links. I do see a few cases where you may need to understand the aggregate in/out traffic on a link, but those cases are usually limited to situations where you either a) are getting billed for the total amount of traffic in/out of a location by your service provider or b) you're concerned about the total amount of traffic going through a device. "b" is only typically a concern if you're sending an extremely high amount of some very specific traffic types and you'll probably be working directly with your hardware vendor if you suspect that this is the issue.
So, let's assume that we're analyzing the network traffic in each direction separately. Next, you need to understand that each network interface is unique - meaning that you have to evaluate each hop separately along the traffic path. Case in point - we get asked sometimes for "network wide" bandwidth utilization reports or for reports that aggregate these statistics for all of the links along a specific path. As an engineer, I can't think of a case where I've actually used this data other than to satisfy the curiosity of some executive that didn't really understand network traffic anyway and was basically trying to figure out if they were spending too much on bandwidth or not. So in a nutshell, you need to analyze each LAN link or network interface separately and you need to analyze the traffic going in each direction separately. Effectively, for every link between two devices you now have 4 different places to look for issues. Trust me, it's much more complicated to try to troubleshoot an application performance issue over the network without this knowledge - even though at first it may seem complicated.
The next thing that's really important as it relates to analyzing network traffic and performance is understanding the difference between bandwidth and latency. To go back to our highway example, imagine that the bandwidth is the number of lanes that have going in each direction. If you have the same number of lanes going to and from the destination then you could say that your bandwidth is symmetrical. However, many times, for instance if you have a broadband connection at home, there will be only say 2 lanes heading away from your house and 10 lanes heading towards it. In this case you would consider the link to be asymmetrical.
Latency quite simply is the amount of time that takes to drive to the other end of the highway and back. This is usually described as Round Trip Latency (RTL) or Round Trip Time (RTT). In some cases you'll see the latency measurement broken out for each direction, but not commonly.
Anyhow, that's a very quick summary of some things that you need to know in order to get started with understanding how to measure your network traffic. I'll stop here otherwise nobody will read this far :) If you're interested in hearing more on this subject or if you're interested in understanding how to more deeply analyze a specific type of network traffic or network topology, please let me know.
Now to Pay the Bills...For those of you that have Orion, you'll see that when you look at the Interface Details page for a managed interface you see not only the average bandwidth utilization in each direction (receive and transmit) but you'll also see high and low water markers. This is really important, because you need to understand how often and for how long your network traffic spikes to the maximum allowable level. Additionally, if you have the VoIP module, you can view latency as it is measured from the remote router to the device on the other end of its WAN connections. This is pretty cool, especially if you put it on the same page with the other interface details and statistics and can really make it quick and easy to diagnose network performance issues. If you don't have Orion, you can still check it out on our online demo server at:
http://oriondemo.solarwinds.com
I read an interesting article today by Bill Brenner over at SearchSecurity about how network configuration can affect network security. You can read the article: here
While this topic is somewhat parallel, the article got me to thinking about how many times we focus on what we have to do with regards to security vs. what we should do. Nearly every day I hear someone talking about the extra work that SOX or HIPAA has caused them and I see them focusing much of their time, especially with regards to security, in these areas. It's gotten so bad that many people think that the terms "security" and "compliance" are one and the same. Do a quick Google search on these topics and you'll see what I mean.
While compliance can certainly be important, focusing exclusively in this area seems to me sort of like considering yourself safe driver just because your wear a safety belt and obey the speed limit.
Let's face it - if your company is required by law to think about things like SOX or HIPAA then as a hacker I'm not going to focus my attention in those areas. Instead, I'm going to look for the things that you probably didn't have time to worry about and/or are more abstract in terms of achieving compliance. Some of the top items that people overlook are:
1. Physical security - there are a lot of things that fit into this area all the way from securing access to your switch ports/LAN drops to making sure your users aren't leaving their passwords written down at their desk (more and more common with today's trend of requiring ever more complex and frequently rotating passwords).
2. Network Application/Traffic Security - is there really a valid reason to allow outbound telnet, RDP, FTP, and SSH connections from your network? What about allowing RDP/telnet security from a user subnet into your core routers?
3. Configuration Management - if someone makes a change on one of your devices are you paged? Do you compare the current configs of your routers and firewalls to the configs from last month and validate the changes against an engineering work order or some other tracking mechanism?
With regards to configuration management, there's really no excuse not to have a solid solution in place in today's day and age. A few years ago the choices were limited to very expensive and hard to use enterprise apps or open source applications and the time investment that those imply. That simply isn't the case anymore - take the Cirrus Configuration Manager we offer here at SolarWinds for instance. Very easy to use, inexpensive, and meets most of the common use cases for config management in the enterprise today.
Let me know if this is a topic (network security) that you'd like to read more about and I'll start including some deeper content in this area.
Head Geek's Top 10 Most Annoying Topics in Networking
10. Overlapping IP address ranges. Let's face it folks, if you've inherited a bunch of overlapping or duplicate address ranges you're going to be better off just to figure out a solid addressing strategy and readdress the problem areas. Otherwise, you'll be stuck trying to work around this issue forever...
9. "Classful" IP Address speak. When people are speaking about any /24 as a "Class C" or any /16 as a " Class B" it just gets in my craw...
8. Access Lists. There has got to be a better way to implement the features that ACLs provide. Sure they're easy enough for those of us that have been using them for years but for newbies they're a nightmare even when trying to accomplish a relatively simple task.
7. The old "SNMP isn't Secure" compliant. So what exactly is the argument here? Yeah, I use SNMPv2C to poll the devices on my network and the data is transmitted in clear text. Let me tell you, if there is someone running around my network looking at packets with a sniffer there is way more dangerous stuff for them to see than the most recent ifInOctets counter values from one of my WAN routers. And as for SNMPv3, it's great but hardly anyone uses it... Bottom line - there are plenty of ways to secure your SNMP traffic - not managing the network really isn't an option though is it?
6. Over protective DBAs. Dude - we just want to put a database on your gargantuan SQL server and store some statistics there. You'd think I was asking to date your daughter or something...
5. Dress codes. Yeah, this topic isn't technical but all of us networking geeks have to wear clothes to work and we oughta be able to wear whatever the heck we want to wear.
4. Annual budgets without any allocations for lab gear. Hey, if you want me to do my testing on the production network then it's OK by me.
3. Devices that don’t even support the most basic, standard MIBs. Those RFCs are there for a reason people. Implement the standards based stuff then put all of your special, fancy data in your own private MIBs. Don’t skip the prerequisites…
2. SOX. I've seen this used for justification for everything from Exchange mailbox size limits to how often we change the coffee filters. One of these days we’re going to find out that it’s a bigger conspiracy than the murder of JFK and that the whole dang thing was made up by one of the big 5 consulting firms that are pulling in all of the cash telling us about everything we can and can’t do…
1. Copycat network management products. If you can come up with something original then I'm all for it. But if you’re just putting new skins and UIs on existing functionality then what's the point... We don't use these tools because they're pretty, I mean, dude, we spend half our day in a freaking CLI for crying out loud...
Flame on... Josh