In order to manage a network, management tools use several
communication protocols, which assure accurate and detailed
information. The challenge for the management tool is to know which
protocol to use, and how it should be configured so that it could
communicate with the managed nodes. This section describes two
communication protocols, which are used in NNMi: ICMP and SNMP.
What is a communication in NNMi?
NNMi uses ICMP ping and SNMP management protocol for network
monitoring. ICMP may be used for initial device discovery and
availability checks (if configured to use ICMP) and the remaining part
is done by SNMP management protocol. SNMP management protocol is key in
network management; including query device configuration, routing
tables, interface status, and so on. NNMi works with SNMP version 1,
2c, and 3. In order to communicate with NNMi and managed devices via
SNMP, NNMi needs to know which community names to use for accessing
devices. In general, NNMi needs to have configured the following
communication data:
- ICMP: It needs to be configured if ICMP pings are used for monitoring
- SNMP community names
- Delay and the number of retries
The section entitled Configuring SNMP community name in NNMi describes how to configure SNMP community names in NNMi, change delays and the number of retries.
What is the role of ICMP in NNMi?
By default, SNMP protocol is used for communication between the
management server and a managed node, but NNMi can also be configured
to make a status poll for some, or all, IP addresses using ICMP ping.
Be cautious using ICMP, as ICMP is not as powerful as SNMP. For example:
- Some addresses may not be reachable from an NNMi server.
- ICMP can be used only for interfaces, which have an IP address only.
- ICMP
can only tell if an IP address is reachable, while SNMP can also
determine the reason, whether the interface is administratively or
operationally up or down. Also, SNMP can determine the status of all
interfaces on the node by reading their SNMP OIDs without polling every
interface.
In short, ICMP only pings IP addresses, while SNMP gets full
configuration and monitors interfaces whether or not they have an IP
address assigned.
Example: Assume NNMi needs to poll the status of all interfaces on
node A. The following figure shows how the node is reached by NNMi.
NNMi can reach router A via interface A. NNMi can also reach interface B, but NNMi has no route to interfaces C and D.
If you are using a status polling via ICMP, then NNMi can reach only
interfaces A and B, and has no status information about interfaces C
and D (they will be considered unreachable).
If you are using SNMP status polling, NNMi queries the node's SNMP MIB (Management Information Base)
on node A for information about all interfaces via interface A, and,
device responds to NNMi about a list of all interfaces on router A
(during configuration check polls) and reports status of all interfaces
(during status polling).
What is the role of SNMP in NNMi?
For SNMP, in order to communicate with NNMi server and the managed node, the following needs to be done:
- Managed node has SNMP enabled and SNMP community name set or username and password if it's SNMPv3.
- NNMi server has to know that SNMP community's name (SNMP configuration).
As SNMP protocol was improved over the time, protocol versioning was introduced. Now there are three major SNMP versions used:
- SNMPv1: This is the first version of protocol. It is described by RFC 1155 and RFC 1157.
- SNMPv2c:
This is an updated version of SNMPv1, and is described by RFC 1901, RFC
1905, RFC 1906, and RFC 2578. This version expanded 64bit counter
support. Getbulk operation was introduced, which allows sending
messages in bulk and saving network resources.
snmpinform command was introduced, which allows us to send a confirmed notification. - SNMPv3: This version was created for improvements in security. The following features were introduced:
- Authentication
- Privacy
- Authorization and access control
It is also very important that all traffic sent by this version of
SNMP is encrypted, so passwords cannot be read using network analyzers
(for example, WireShark).
Main difference between SNMP versions from a security point of view
is that SNMPv1 and v2c sends information through a network as plain
text, while SNMPv3 uses encryption. SNMPv1 and v2c security is
organized using SNMP community names (can be considered as a password),
which is also sent via the network in plain text. SNMPv3 uses usernames
and passwords, which are allowed to control which OIDs can be
accessible to users and usernames. Passwords are also sent via the
network as encrypted.
If you are not sure which version you should use, my recommendations are:
- Use SNMPv3 whenever your devices support this version.
- If
not, use read-only community names for SNMPv1 and v2c, as NNMi doesn't
make any changes to managed devices, but only reads and collects data
and NNMi has no need for writing community names.
There can be configured SNMP communities in three ways using NNMi SNMP communication settings:
- Node specific settings: Here you can set community names for specific nodes.
- Region settings: Community names for address ranges can be set using this tab.
- Default community settings: A default community name is set for all other devices, which are not in the previous lists.
It is recommended to use region settings as much as possible, and to
use specific node settings only when you cannot define a node's
community without using a combination of the region and default settings.
How NNMi deals with overlapping SNMP community configuration
Because NNMi has three ways to define SNMP community names for
managed nodes (node specific, region, and default), it is obvious that
community settings for some nodes may overlap. That is, we have node
192.168.1.1, which has the SNMP community name Secret-123. This node is configured in NNMi's Communication Configuration view as node specific, and the rest of these subnet nodes have SNMP community names Secret-000 and that's configured in region settings. At the same time, the default community name in NNMi Communication Configuration view is set as public.
So, looks like node 192.168.1.1 passes all these three zone community
configurations. This is how NNMi decides which community name to use.
Region settings supersede default community settings and node
specific supersedes region settings. This gives us flexibility in
configuring communities and avoids the hassle of configuring every
device separately.
So, as described in our example, NNMi will use the Secret-123 (node specific) SNMP community for node 192.168.1.1.
Best practices when configuring SNMP communities
To make your life easier, it is recommended that you follow the SNMP
community naming convention, however if you decide to create your own
naming conventions, I can give the following suggestions:
- Don't set read-write community for NNMi—it uses only read-only.
- Avoid
special symbols in your community names, such as: @,:,&,%,$,#,",;
(semicolon), and (comma). Not only does NNMi not support the @ symbol,
but you may have some other software in your environment which uses
SNMP for communication and application code. These special characters
may cause communication problems, bugs, or software hangs. Even if you
don't have any additional software for now, don't forget that you may
have it in future.
- Give
common names for node groups, which are administered by the same staff.
That is, if your backbone and distribution network is administered by
different groups and the access network is administered by remote
groups, depending on the location you may want to configure the
following SNMP community names: one name for all backbone network
devices, another for distribution network devices, and each access
network device would have a community name based on branch office to
which it belongs. Then you don't have to worry, as distribution network
staff won't mess with the backbone or access network devices, and
access network engineers won't mess with the backbone or distribution
network devices.
- Give
different community names for separate nodes only if you have specific
security requirements for particular device/devices. Otherwise, I would
consider it when changing names more frequently.
- Change
community names periodically. Frequency should be chosen based on
security requirements and the effort required to change names. If you
have a configuration management tool (like Cisco Works, HP ProCurve
Manager, or HP SW Network Automation Service), it doesn't take too long
to change names. If this is the case, changing names once every three
months would be a reasonable. If you have dozens or even hundreds of
devices, and the entire configuration has to be done manually, I would
say once a year would be great. Honestly, I've met only a few companies
where community names are changed more frequently than once a year.
|
