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 MESSAGES
- 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
- Enable R5 to send traps for BGP only
- 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 READONLY for the view RESTRICT
- 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)
Tags: CCIE, CCIE R&S, ccie r&s written, CCIE Training






Thanks man, GOod post Very informative