Most network admins and engineers are familiar with SNMPv2c which has become the dominant SNMP version of the past decade. It’s simple to configure on both
the router/switch-side and just as easy on the network monitoring server. The problem of course is that the SNMP statistical
payload is not encrypted and authentication is passed in cleartext. Most companies have decided that the information being transmitted isn’t valuable enough to be
worth the extra effort in upgrading to SNMPv3, but I would suggest otherwise.
Like IPv4 to IPv6, there are some major changes under the hood. SNMP version 2 uses community strings (think cleartext passwords, no encryption) to
authenticate polling and trap delivery. SNMP version 3 moves away from the community string approach in favor of user-based authentication and view-based
access control. The users are not actual local user accounts, rather they are simply a means to determine who can authenticate to the device. The view is used to
define what the user account may access on the IOS device. Finally, each user is added to a group, which determines the access policy for its users. Users,
The following security models exist: SNMPv1, SNMPv2, SNMPv3. The following security levels exits: “noAuthNoPriv” (no authentiation and no encryption noauth
keyword in CLI), “AuthNoPriv” (messages are authenticated but not encrypted auth keyword in CLI), “AuthPriv” (messages are authenticated and encrypted priv
keyword in CLI). SNMPv1 and SNMPv2 models only support the “noAuthNoPriv” model since they use plain community string to match the incoming packets. The
SNMPv3 implementations could be configured to use either of the models on per-group basis (in case if “noAuthNoPriv” is configured, username serves as a
replacement for community string).