Bandwidth optimization for network management systems
For some IT departments, there is an absolute rule: “No network infrastructure gets implemented unless it can be monitored,” and it used to make good sense. Complex networks have many different components and when an end users start complaining that the network is down you need to know how to diagnose the problem. Half the battle was finding which component is not performing as prescribed and where it is located. Preferably you would like to know before the end user starts to complain if an issue is brewing, enter the NMS (Network Management System).
NMS systems are deployed by Network Engineers to track “up time,” how much data is flowing, CPU temps, and a variety of other conditions that help the administrators know what is going on at any given point in time in their network. Most administrators would not even give a second glance at a component that couldn’t report back to their NMS. We understand that so we made sure it talks the talk and walks the walk.
The Simple Network Management Protocol (SNMP) Daemon, located at Services > SNMP, allows querying certain status information from the RBA with an SNMP client, such as those in network monitoring systems.
At a minimum, to enable the service, set a Polling Port (Default is udp/161) and a Read Community String. It is strongly recommended that the Read Community String be changed, as the default “public” value is a well-known default across vendors and may lead to unintended information leaks.
SNMP trap generation may also be enabled. Fill in the Trap server, Trap server Port, and SNMP Trap String.
Modules for the SNMP daemon may also be loaded or unloaded. Modules provide specific collections of information or capabilities for the SNMP daemon, but they also consume more system resources to do so. Reducing the number of modules also limits the amount of information that could be exposed via SNMP should the service be queried by an untrusted source.