SNMP Practical Exercises (Hands-on)

VN:F [1.9.6_1107]
Rating: 3.0/5 (4 votes cast)
By Terry Vinson on June 19th, 2012

INTRODUCTION

This mini-configuration lab, dealing with SNMP, will be conducted using three routers connected via FastEthernet. We will run OSPF area 0 on all devices and advertise all configured interfaces into OSPF process 1. This network is simple enough to be emulated on dynamips/dynagen, GNS3 or through the use of live equipment. In my case I will be using Proctorlabs gear connected according to the following topology:

TASK 1.1 – SNMP POLLING

  • Configure two communities on R5 fitting the following policy
    • Community MESSAGES
      • provide only the ability to retrieve information
      • Restrict access such that any only R1 and R4 loopback0 interfaces will successfully poll this SNMP agent
  • Community CONTROL
    • provide complete SNMP access to the polling devices
    • Restrict access such that only R1 and R4 lo 0 interfaces will successfully poll this SNMP agent
  • Ensure that failed attempts from any devices not expressly allowed will be logged to the console.

Task 1.1 – SNMP POLLING Solution

LAB_R5#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

LAB_R5(config)#

LAB_R5(config)#access-list 1 permit 172.16.1.1

LAB_R5(config)#access-list 1 permit 172.16.4.4

LAB_R5(config)#access-list 1 deny any log

LAB_R5(config)#!

LAB_R5(config)#snmp-server community MESSAGES ro 1

LAB_R5(config)#snmp-server community CONTROL rw 1

Task 1.1 – SNMP POLLING Verification

There are no active NMS workstations on the CCIE Exam however that will not prevent them from possibly tasking a student to make a SNMP configuration. In the absence of an NMS we will have to rely on show commands to verify whether or not the configuration has been completed such that it satisfies the parameters of the task. This can best be accomplished by using the show snmp community command on the managed device (LAB_R5):

LAB_R5#show snmp community

Community name: ILMI

Community Index: cisco0

Community SecurityName: ILMI

storage-type: read-only  active

Community name: MESSAGES

Community Index: cisco5

Community SecurityName: MESSAGES

storage-type: nonvolatile        active access-list: 1

Community name: CONTROL

Community Index: cisco6

Community SecurityName: CONTROL

storage-type: nonvolatile        active access-list: 1

The output of this command reveals that we currently have 3 communities running on R5, but only two of these communities have active access-lists applied to them. To verify the nature of the ACL that has been applied to the community string we simple need to use the show access-list command:

LAB_R5#show access-list 1

Standard IP access list 1

10 permit 172.16.1.1

20 permit 172.16.4.4

30 deny   any log

We see that access-list 1 has two permit entries matching the loopback0 interface of both R1 and R4, as well as a deny any log entry at sequence number 30. These will first force the access-list to count the number of denied attempts (information that would be lost without the explicit deny) and the log option will force console messages each time traffic is denied.

Notification Operations

We have discussed the theory and operation of SNMP and now it is time to look at how to deploy it at the command line. To make things easier to understand we will begin by configuring a typical trapping or notification operation.  Remember that in this configuration the SNMP agent running on the managed device will send a trap or inform message to the NMS when a monitored state transition takes place.

TASK 1.2 — SNMP NOTIFICATIONS

  • Configure two communities on R5 fitting the following policy
    • Enable R5 to send traps for BGP only
      • set the location as VIRGINIA
      • set the managed device chassis-id as 123-45678
      • allow R5 to be reloaded via SNMP
  • Trap Specifications
    • Traps should be sourced from R5’s Loopback0 interface
    • Send all traps to the NMS located at 172.100.100.100
    • Use the community string BGPTRAPS
    • Send the bgp traps via SNMPv2

Task 1.2 – SNMP NOTIFICATION Solution

LAB_R5#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

LAB_R5(config)#snmp-server enable traps bgp

LAB_R5(config)#snmp-server location VIRGINIA

LAB_R5(config)#snmp-server chassis-id 123-45678

LAB_R5(config)#snmp-server system-shutdown

LAB_R5(config)#!

LAB_R5(config)#snmp-server trap-source loopback0

LAB_R5(config)#snmp-server host 172.100.100.100 version 2c BGPTRAPS bgp

LAB_R5(config)#

Task 1.2 – SNMP NOTIFICATION Verification

The parameters of this task can be verified with the show snmp host command.  This command will show the communities configured on R5.

LAB_R5#show snmp host

Notification host: 172.100.100.100      udp-port: 162   type: trap

user: BGPTRAPS  security model: v2c

We can see details associated with the user BGPTRAPS via the show snmp community command:

LAB_R5#show snmp community

Community name: ILMI

Community Index: cisco0

Community SecurityName: ILMI

storage-type: read-only  active

Community name: BGPTRAPS

Community Index: cisco1

Community SecurityName: BGPTRAPS

storage-type: nonvolatile        active

We can see the additional parameters that have been configured via the show snmp command.

LAB_R5#show snmp

Chassis: 123-45678

Location: VIRGINIA

0 SNMP packets input

0 Bad SNMP version errors

0 Unknown community name

0 Illegal operation for community name supplied

0 Encoding errors

0 Number of requested variables

0 Number of altered variables

0 Get-request PDUs

0 Get-next PDUs

0 Set-request PDUs

0 Input queue packet drops (Maximum queue size 1000)

0 SNMP packets output

0 Too big errors (Maximum packet size 1500)

0 No such name errors

0 Bad values errors

0 General errors

0 Response PDUs

0 Trap PDUs

SNMP Trap Queue: 0 dropped due to resource failure.

SNMP logging: enabled

Logging to 172.100.100.100.162, 0/10, 0 sent, 0 dropped.

LAB_R5#

We can see the nature of the information sent by the trap SNMP agent by turning on debug snmp packets and creating a bgp session. For the purpose of this illustration we will use the autonomous system 100 in this demonstration.

LAB_R5#debug snmp packets

SNMP packet debugging is on

Now for the routing process:

LAB_R5#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

LAB_R5(config)#router bgp 100

LAB_R5(config-router)#neighbor 1.1.1.1 remote-as 100

LAB_R5(config-router)#exit

LAB_R5(config)#exit

 

After a short period of time we see the following:

LAB_R5#

*Jan  1 13:46:57.182: SNMP: Queuing packet to 172.100.100.100

*Jan  1 13:46:57.182: SNMP: V2 Trap, reqid 1, errstat 0, erridx 0

sysUpTime.0 = 1557120

snmpTrapOID.0 = ciscoBgp4NotifyPrefix.1

bgpPeerEntry.14.1.1.1.1 = 00 00

bgpPeerEntry.2.1.1.1.1 = 3

cbgpPeerEntry.7.1.1.1.1 =

cbgpPeerEntry.8.1.1.1.1 = 1

We see the SNMP message being queued to be sent to the NMS located at 172.100.100.100, and that this packet’s format is a SNMPv2 sequence, also observe the actual MIB values that are being communicated (*PeerEntry.x.x.x.x.x). These values use the OID format we discussed previously

Note: This method of using debug snap packet is a handy and simple way to identify the OID numbers used by the SNMP process.

Context-Based Access Restriction

In this task we will make certain that an NMS using the community string READONLY or CONTROL will have restricted access to the root branch of the SNMP MIB tree.

TASK 1.3 – SNMP CONTEXT-BASED ACCESS

  • Configure a single view called RESTRICT on R5
    • Provides root access to the snmp ‘root’
    • Restrict access to the following OID variables
      • 1.3.6.1.2.1.4.21
      • 1.3.6.1.2.1.4.22
      • 1.3.6.1.2.1.3
      • 1.3.6.1.6.3.15
      • Configure two communities on R5 fitting the following policy
        • Community READONLY for the view RESTRICT
          • provide read only access
  • Community CONTROL
    • provide complete SNMP access to the view RESTRICT

Task 1.3 – SNMP CONTEXT-BASED ACCESS Solution

LAB_R5#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

LAB_R5(config)#

LAB_R5(config)#

LAB_R5(config)#snmp-server view RESTRICT iso included

LAB_R5(config)#!

LAB_R5(config)#snmp-server view RESTRICT 1.3.6.1.2.1.4.21 excluded

LAB_R5(config)#snmp-server view RESTRICT 1.3.6.1.2.1.4.22 excluded

LAB_R5(config)#snmp-server view RESTRICT 1.3.6.1.2.1.3 excluded

LAB_R5(config)#snmp-server view RESTRICT 1.3.6.1.6.3.15 excluded

LAB_R5(config)#!

LAB_R5(config)#snmp-server community READONLY view RESTRICT RO

LAB_R5(config)#snmp-server community CONTROL view RESTRICT RW

Task 1.3 – SNMP CONTEXT-BASED ACCESS Verification

A single show snmp view command will reveal the views that have been configured on R5:

LAB_R5#show snmp view

*ilmi system – included permanent active

*ilmi atmForumUni – included permanent active

RESTRICT iso – included nonvolatile active

RESTRICT at – excluded nonvolatile active

RESTRICT internet.6.3.15 – excluded nonvolatile active

RESTRICT ip.21 – excluded nonvolatile active

RESTRICT ip.22 – excluded nonvolatile active

v1default iso – included permanent active

v1default internet.6.3.15 – excluded permanent active

v1default internet.6.3.16 – excluded permanent active

v1default internet.6.3.18 – excluded permanent active

v1default ciscoMgmt.394 – excluded permanent active

v1default ciscoMgmt.395 – excluded permanent active

v1default ciscoMgmt.399 – excluded permanent active

v1default ciscoMgmt.400 – excluded permanent active

 

Terry Vinson
CCIE#35347 (R&S)

SNMP Practical Exercises (Hands-on), 3.0 out of 5 based on 4 ratings
Share and Enjoy:
  • RSS
  • Twitter
  • Facebook
  • Google Bookmarks
  • Digg
  • Print
  • Technorati
  • Slashdot
  • LinkedIn
  • del.icio.us
  • Reddit
  • Sphinn
  • Mixx
  • Blogplay
  • Netvibes
  • NewsVine
  • Live
  • Ping.fm
  • MySpace
  • Yahoo! Bookmarks
  • Yahoo! Buzz

Tags: , , ,

One Response to “SNMP Practical Exercises (Hands-on)”

  1. Hemanth Raj says:

    Thanks man, GOod post Very informative

    VA:F [1.9.6_1107]
    Rating: 0.0/5 (0 votes cast)

Leave a Reply