Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Cacti 0.8 Beginner's Guide

You're reading from   Cacti 0.8 Beginner's Guide Learn Cacti and design a robust Network Operations Center

Arrow left icon
Product type Paperback
Published in Mar 2011
Publisher Packt
ISBN-13 9781849513920
Length 348 pages
Edition 1st Edition
Languages
Tools
Concepts
Arrow right icon
Author (1):
Arrow left icon
Thomas Urban Thomas Urban
Author Profile Icon Thomas Urban
Thomas Urban
Arrow right icon
View More author details
Toc

Table of Contents (23) Chapters Close

Cacti 0.8Beginner's Guide
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
1. Installing Cacti FREE CHAPTER 2. Using Graphs to Monitor Networks and Devices 3. Creating and Using Templates 4. User Management 5. Data Management 6. Cacti Maintenance 7. Network and Server Monitoring 8. Plugin Architecture 9. Plugins 10. Threshold Monitoring with Thold 11. Enterprise Reporting 12. Cacti Automation for NOC Mobile Access / Administration Online Resources Further Information Pop Quiz Answers
Index

SNMP: The Simple Network Management Protocol


When it comes to network management protocols, the Simple Network Management Protocol (SNMP) is probably one of the best known. It is commonly used in networks and several applications internally support SNMP for monitoring purposes.

In this section, we will only provide a short overview of SNMP because its full workings are beyond the scope of this book.

The Management Information Base

SNMP stores information in a virtual database called a Management Information Base (MIB). The database is hierarchical (tree-structured) and entries are addressed through object identifiers (OID). The following SNMP table output shows this structure:

.1.3.6.1.2.1.25.3.8.1.1.1 = INTEGER: 1
.1.3.6.1.2.1.25.3.8.1.1.2 = INTEGER: 2
.1.3.6.1.2.1.25.3.8.1.2.1 = STRING: "/"
.1.3.6.1.2.1.25.3.8.1.2.2 = STRING: "/boot"
.1.3.6.1.2.1.25.3.8.1.3.1 = ""
.1.3.6.1.2.1.25.3.8.1.3.2 = ""
.1.3.6.1.2.1.25.3.8.1.4.1 = OID: .1.3.6.1.2.1.25.3.9.23
.1.3.6.1.2.1.25.3.8.1.4.2 = OID: .1.3.6.1.2.1.25.3.9.23
.1.3.6.1.2.1.25.3.8.1.5.1 = INTEGER: readWrite(1)
.1.3.6.1.2.1.25.3.8.1.5.2 = INTEGER: readWrite(1)
.1.3.6.1.2.1.25.3.8.1.6.1 = INTEGER: true(1)
.1.3.6.1.2.1.25.3.8.1.6.2 = INTEGER: false(2)

The number to the left represent the OIDs, the data to the right are the actual values of that OID. If you look at the OIDs to the left, you can see the actual tree structure:

.1.3.6.1.2.1.25.3.8.1.
                    \--1
                       \--1
                       \--2
                    \--2
                       \--1
                       \--2

Generally an organization that has an SNMP agent will publish an MIB-Module for their product and this is used on the management station to map the OIDs to human readable equivalents and perform some basic sanity checks on the format of data returned.

SNMPv1

SNMPv1 is the original SNMP protocol defined in the late 1980s. One of the main design goals for SNMP was to keep it simple and easy to implement. Due to this decision, SNMPv1 gained widespread commercial relevance and today most manageable network equipment supports at least SNMPv1.

By keeping it simple on the agent (network equipment) side, more complex tasks were left to the clients.

SNMPv1 had 5 core protocol data units (PDUs) for getting and setting data as well as sending out alerts. These are:

  • GetRequest

  • GetNextRequest

  • SetRequest

  • Response

  • Trap

The GetRequest and GetNextRequest units are used to retrieving data from an agent but they can only retrieve one data point at a time, so retrieving interface statistics on a large network device requires many GetRequests or GetNextRequests to be sent to the device.

With the SetRequest unit, data can be set on the device. This is typically used to change configurations (e.g. on Cisco routers/swtiches), or for sending commands to a network device (e.g. ping).

The Response unit is sent by the SNMP agent to the management station as a response to a Get or Set request.

Traps are initiated from the SNMP agent to send immediate alerts to the defined management station. They include information about:

  • Who is sending the trap

  • What occurred

  • When it occurred

  • Additional information as OID/value pairs

Cacti itself does not handle SNMP traps. There are several plugins available for adding this functionality to Cacti.

Security

SNMPv1 does not have any encryption and only uses a community string to identify the management station, and even then it is transmitted in clear text. As a result, SNMPv1 is a very insecure protocol because SetRequests can be used to reconfigure network equipment if improperly configured.

Modern network equipment allows the definition of access lists for requests to the SNMP agent which should be used in order to reduce security issues.

SNMPv2 / SNMPv2c

SNMPv2 addresses some of the shortcomings of the SNMPv1 protocol by introducing two new protocol data units: GetBulkRequests and InformRequest.

The GetBulkRequest unit allows a single GetRequest to retrieve numerous OIDs from an SNMP agent without the need to send several GetRequests. This is particularly useful for retrieving large amounts of objects such as a list of all interfaces of a network device.

The Inform unit addresses the unreliability of the Trap unit, which sends a unidirectional trap. In contrast to this, Informs provide a mechanism to send reliable events from the agent to the management station, which is then acknowledged with a response so that the notification is confirmed by the agent.

With SNMPv2 there was also an update to the MIB definition, which was enhanced to support more data types such as IPv6 addresses, Octet strings and 64-bit counters.

Security

Although SNMPv2 was also supposed to address the security deficits of SNMPv1, it still uses un-encrypted communication, secured only by a community string and access control lists. This is also reflected by the additional "c" in SNMPv2c.

SNMPv3

SNMPv3 does not add new operations or enhancements to the MIB, but addresses the security problems of SNMPv1 and SNMPv2c. It can be seen as SNMPv2c plus additional security, as it allows message encryption and strong authentication of senders.

SNMP support in Cacti

Cacti supports all three versions of the SNMP protocol which allows legacy equipment to be monitored alongside the latest devices.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image