I have two more questions to ask. First of all, what is the use of EngineIDs in SNMPv3? I’ve heard that they make the managed devices unique, but why do we care about something like that?
The second thing is, my OCG book mentions the following when it comes to troubleshooting SNMP
Preventing indexes from shuffling - To prevent index shuffling and guarantee index persistence during reboots or minor software upgrades, use the snmp-server ifindex persist command which shows up as snmp ifmib ifindex persist in the running config.
I am pretty confused by this. What is an index? What is shuffling? What happens if indexes are shuffled?
You’re on the right track with your understanding of SNMPv3 Security Models. Let me just add a couple of points for each one that will help in understanding. We can gain insight into what is actually being performed from the names of the keywords themselves:
NoAuthNoPriv - NoAuth means no cryptographic authentication. Credentials are used, but there is no cryptographic mechanism to verify the authenticity of the message. NoPriv means no privacy of the contents of the SNMP messages, meaning there is no encryption of the payload.
AuthNoPriv - Auth means there is cryptographic authentication. It uses MD5 or SHA for this purpose. The authentication mechanism is actually applied to the associated user using the snmp-server user command. The NoPriv remains in this security model as described above.
AuthPriv - As in the previous model, Auth means cryptographic authentication is employed.
Priv indicates that the whole SNMP packet is encrypted, which means if the packet is intercepted, it cannot be deciphered.
From the above description, you can see that while AuthNoPriv does hash the password, the rest of the SNMP packet is sent in clear text. AuthPriv however encrypts the contents of the SNMP packet. Because SNMP messages can contain vital information about the configuration and state of a network, it can potentially be dangerous if intercepted and read.
Regarding your last question, you’re correct again. When configuring priv (privacy or encryption), you need to specify an encryption algorithm and a key. This key is used to both encrypt and decrypt the message. Both sides of the communication must have the same key in order to successfully decrypt the message.
The Engine ID is a feature specific to SNMPv3, and was introduced as part of its enhanced security model. The engine ID uniquely identifies each SNMPv3 entity, be it an SNMP agent or an SNMP manager. The uniqueness of the ID is crucial for security purposes, keeping in mind that SNMPv3 has added security features compared to its predecessors. The Engine ID is used in the generation of security parameters, and it helps to ensure that the communication is indeed with the correct device. Without unique Engine IDs, there could be potential for security breaches or miscommunication. Some more info about this feature and how its configuration affects the SNMP setup can be found in this Cisco documentation:
When a device boots up, SNMP assigns a particular index to identify each individual interface on that network device. These indexes are used by SNMP to identify the specific interface for which it’s collecting statistics.
Shuffling of these indexes can occur during a reboot or a minor software upgrade. This is especially true if virtual interfaces, SVIs, tunnels, or loopback interfaces have been configured over the lifetime of the device. When a reboot occurs, the order that the indexes have been assigned may change.
This means that the index previously assigned to a particular interface might be assigned to a different interface after the reboot or upgrade. This can cause confusion and inaccuracies in your network monitoring, as the SNMP manager might collect data for the wrong interface.
The command snmp-server ifindex persist (or snmp ifmib ifindex persist in the running config) is used to prevent this shuffling. It ensures that the same index is assigned back to the same interface even after a reboot or software upgrade, hence maintaining accuracy in your network monitoring.
Hello Rene, great article, im trying to use Observium , on my router i have a principale line and a backup line, i can monitor only one IP configured on the same IP event if i try to bring up a vritual management IP that is proxied on both pubblic ips but obsermium only permited to add only one pubblic ip, is there a workaorund?
Although Observium is used within the lessons, the focus is not on the use of this NMS system, so our aid in this area may be limited. However, doing some research, I have found that it may be possible for a workaround.
You’re correct that you can only add one IP address per device. However, you should be able to add the same device twice, once for each IP address. That way, Observium will see the single device as two entities, one for each of its IP addresses.
Specifically:
Add the device using the primary IP address and let Observium discover and poll it.
Then, add the same device again but this time use the second IP address.
This will let you monitor both IP addresses. The downside is that Observium will treat these as two separate devices, which may not be ideal for your monitoring needs.
Also, remember to configure SNMP on both IPs on your router. If SNMP is not enabled on the second IP, Observium will not be able to poll it.
As noted in the lesson, Observium has been forked to LibreNMS, and typically it is a better choice, so you may want to try that.
Hi Laz,
thanks, i will try to use LibreNMS, i created a Loopback interface that is proxied on both ips but i can only add one ip and not also on the second, the error that i received on observium is:
Already got device with SNMP-read sysName (name of device), ‘snmpEngineID’ = 80001E4104303044304436 and ‘entPhysicalSerialNum’ = 0008D2 .
The error message you’re receiving indicates that Observium is detecting a conflict. It seems to be identifying the second IP address as belonging to a device that it’s already monitoring.
A possible workaround could be to try and add the second IP address as a new device but with a different sysName. This might trick Observium into treating it as a separate device. However, this workaround might not be ideal as it could lead to some confusion in your network monitoring.
Another option would be to check if you have SNMP correctly configured on both IP addresses. If SNMP is not correctly set up on the second IP, Observium might not be able to recognize it as a separate entity.
In any case, if you do try out LibreNMS, you may find that the problems you are facing will be resolved. Let us know how you get along!
The “noAuthNoPriv” option, even though it does say “noAuth” still requires the use of a username. The noAuth portion of the name actually indicates that SNMP messages are not authenticated. This means that the message’s integrity and the identity of the sender are not verified, but a username is still necessary. And the “NoPriv” portion indeed means that there is no encryption as you state. Does that make sense?
I hope this has been helpful!
Laz
is from SNMP (Simple Network Management Protocol) security model and it stands for “No Authentication, No Privacy”. This means that the SNMP messages are sent in plain text and no authentication is required to access the SNMP objects. It’s the least secure mode and is generally not recommended for most SNMP implementations due to its potential security vulnerabilities.