programming4us
programming4us
ENTERPRISE

HP Network Node Manager 9 : Discovering and Monitoring Your Network - Configuring communication protocols (part 1)

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
2/18/2015 2:26:50 AM

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.

What is the role of ICMP in 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).
    What is the role of SNMP in NNMi?

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.
Other  
  •  HP Network Node Manager 9 : Discovering and Monitoring Your Network - How discovery works
  •  Commercial Backup Utilities : Reduction in Network Traffic
  •  Commercial Backup Utilities : Data Requiring Special Treatment, Storage Management Features
  •  Commercial Backup Utilities : Simultaneous Backup of Many Clients to One Drive, Disk-to-Disk-to-Tape Backup, Simultaneous Backup of One Client to Many Drives
  •  Commercial Backup Utilities : Backup of Very Large Filesystems and Files, Aggressive Requirements
  •  The HP Virtual Server Environment : Virtual Partition Example Scenario (part 8) - Using a Script to Migrate CPUs
  •  The HP Virtual Server Environment : Virtual Partition Example Scenario (part 7) - Configuring an nPartition and Virtual Partitions for Auto-Booting
  •  The HP Virtual Server Environment : Virtual Partition Example Scenario (part 6) - Creating the Second Virtual Partition, Booting the Second Virtual Partition
  •  The HP Virtual Server Environment : Virtual Partition Example Scenario (part 5) - Virtual Partition States, Booting the First Virtual Partition
  •  The HP Virtual Server Environment : Virtual Partition Example Scenario (part 4) - Installation of Virtual Partitions
  •  
    Top 10
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
    - Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
    - Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
    REVIEW
    - First look: Apple Watch

    - 3 Tips for Maintaining Your Cell Phone Battery (part 1)

    - 3 Tips for Maintaining Your Cell Phone Battery (part 2)
    programming4us programming4us
    programming4us
     
     
    programming4us