When configuring SNMP ACLs, you can create security names with associated security models; group security names together; create custom views that include or exclude specific OIDs by using the VACM that controls who can access which MIB objects under agent management. See About SNMP settings. For example, you can give some users access to critical read/write control data, and give other users access to just read-only data.

Then, you can create access policies that define who gets access to which type of information. Access policies are composed of groups, security levels (no authentication, authentication, private authentication), and views. Access policies are the configurable sets of rules, based on which the entity decides how to process a given request.

Security names define requesters allowed to issue gets and sets (v1 and v2c only). A requester can make changes to the view-based access-control model (VACM) security name configuration. This control does not apply to SNMPv3 queries. Traps for v1 and v2c are independent of the security name.

You can configure security names to include a password-like community string to control access. Use a combination of uppercase, lowercase, and numerical characters to reduce the chance of unauthorized access. Community strings don’t allow printable 7-bit ASCII characters, except for white spaces. Also, the community strings can’t begin with a pound sign (#) or a hyphen (‑).

If you specify a read-only community string (see About SNMP settings), it takes precedence over this community name and allows users to access the entire MIB tree from any source host. If you don’t want to allow users this level of access, delete the read-only community string.

If you want to create multiple SNMP community strings, leave the default public community string and then create a second read-only community string with a different security name. Alternatively, you can delete the default public string and create two new SNMP ACLs with unique names.

These settings are available:

You can organize security names into groups. Groups have two settings: name, and security and name pairs. Available security models are v1, v2c, usm (v3). Use the plus (+) and minus (-) icons to add or remove security and name pairs from the group. Later, when you create access policies, the groups you create here are available for assignment to policies.

Views enable you to group object identifiers (OIDs) into views. When creating a view, you specify which OIDs to include or exclude. Later, when you create access policies, the views you create here are available for assignment to policies.

You can combine groups, views, and a security level to form an access policy. The security level applies to the group, not to an individual user. These security levels for access policies are available: