I had a great post-installation discussion with a network ISP customer last month who was lamenting the fact that it took longer for them to configure their environment for monitoring, than it did to configure Monolith.   We have, for some time now, had best practices documentation that informs customers on how to configure their environment to be effectively monitored, and it’s nothing special.   It is increasingly interesting to me how infrequently organizations utilize standardizations.  One of my favorite quotes is from Linus Torvalds (inventor of Linux) – “The beauty of standards is that there are so many to choose from”.

An alarming number of organizations think they utilize standards well in their IT infrastructures.  Most believe that standards are being followed, but it isn’t until they start to implement a monitoring package that they realize how much of a mess there really is.  This blog will address some of the most common issues we see in customer environments that negatively impacts a monitoring system.

DNS Naming Standards

The average operator and most executives cannot determine much from the IP address of a device and with the advent of IPv6, DNS for all devices will quickly become a necessity.  The biggest confusion point with DNS revolves around the naming standard (what’s in it, what does it mean) and ensuring that forward as well as reverse entries are in the DNS servers.   These are key issues that should be resolved before starting your monitoring effort.

Syslog/Trap Forwarding

Collecting fault information is a common requirement for any network monitoring project.  Your devices want to tell you when they have problems.  You just need to be listening.  Unfortunately, we too often find that customers do not configure this option when they deploy their network devices, which then requires them to double back to configure their trap and syslog destinations.  We like to have this configured prior to coming on site to deploy our monitoring solution, to avoid having to spend time troubleshooting communication path (e.g. ACL) and configuration issues.  For customers looking to get ahead of the curve on this issue, they can use our Event Router to forward their traps and Syslogs to as many destinations as they’d like.

Firewall Rules

Network access issues are a constant concern at client sites.  In order to prep for this, we always document which ports, protocols, and directions are being used so that all the proper configurations and holes can be configured prior to implementation.   This eliminates many common deployment issues.  I highly recommend this approach for any monitoring software implementation.

SNMP ACLs

In my experience, network ACLs cause more problems than firewalls.   Network devices restricting SNMP network access make a lot of sense from a security perspective, but are pesky creatures when it comes to management solutions.  In a perfect world, customers would have a dedicated “management” subnet so that any devices with IP Addresses in that subnet can get access to the devices.   This tactic makes scaling and adding new polling servers extremely easy.  I also find that this is typically a good long term investment into your monitoring administrators sanity.

SNMP Community Strings

I have seen lots of problems with community string configurations.   One fact that not many people realize is the how useless SNMPv1 community strings are.  They are completely un-scalable for polling.  We highly recommend against having any SNMPv1 only devices due to the negative impact on the rest of the polling process.   The second SNMP community string issue is uniformity.  It makes sense to have (where possible) uniform community strings.   This makes discovery easier, and also allows for easier periodic changing of the community strings – which should be done for security reasons.   SNMPv2 works well.  We are finding that interest in SNMPv3 is growing – predominantly for more security-conscious businesses.

Well, that’s all I got for now.   I am sure I could go on for pages about best practices, but the reason why they are so important is because they save you time and lower risk — it just makes business sense.

Technorati Tags:
network management, network monitoring, monolith software, monolith-software.com, technology monitoring, technology management, syslog, traps, DNS naming, IPv6, fault management, SNMP, network access, BSM, SLM, service level management