This latest lab lets you practice configuring SNMP. At the same time, it lets you configure restrictions so that only some devices are allowed to even use SNMP with the routers in the lab. Check out the lab requirements first, write down your own answer, and then come back here to check your answer.
Answers
Figure 1: Two Routers with IP Addresses
Example 3: R1 Config
access-list 1 permit 172.16.1.0 0.0.0.255 access-list 1 remark with only one line, this ACL denies all else ! snmp-server community readonly ro 1 snmp-server community readwrite rw 1 snmp-server location Cincinnati snmp-server contact Chris
Example 4: R2 Config
access-list 1 permit 172.16.1.0 0.0.0.255 ! snmp-server community readonly ro 1 snmp-server community readwrite rw 1 snmp-server location Cincinnati snmp-server contact Chris
Commentary
With SNMP version 2c (SNMPv2c), the only security mechanism was to use a simple text password called a community string. Any NMS with knowledge of the read/write community could then change anything accessible to the SNMP agent on the device, which on Cisco routers and switches includes the configuration. Further securing SNMPv2c by restricting the IP addresses allowed to connect to the router makes sense. (Using SNMPv3 makes even more sense.)
In this case, the snmp-server community commands end with a “1”, which refers to access-list 1. ACL 1 permits all traffic from subnet 172.16.1.0/24, that is, from the subnet in which the NMS resides. Without the “1” on the end, these first two commands would have enabled SNMP, with no ACL to restrict acces, so that anyone who knew the very poorly chosen community values of “readonly” and “readwrite” would have access to the routers using SNMP.
The two remaining commands on each router simply set the location and contact, which SNMP will use as values for two different SNMP variables.