A regional planning commission hardens SNMP access on civic routers with SNMPv3 and wants a companion control that limits which management stations can send SNMP to the box. How can an IPv4 ACL help?
Select an answer to reveal the explanation.
Short Explanation
SNMPv3 checks badges; an ACL checks which desks are allowed to walk up to the agent window. Together you get crypto/auth plus a source allow-list.
Full Explanation
A regional planning commission hardening SNMP access with SNMPv3 and wanting a companion control that limits which management stations can send SNMP to the box can apply an IPv4 ACL that permits SNMP only from approved management-station sources and deny others, binding it to the SNMP agent access controls. SNMPv3 provides authentication and privacy for the management protocol; the ACL adds a source allow-list so unapproved stations cannot even present credentials to the agent. The correct approach works because crypto/auth and transport source restriction are complementary civic hardening layers. Using the ACL only to rewrite SNMPv3 users into SNMPv1 communities automatically fails because ACLs do not translate SNMPv3 users into SNMPv1 and should not downgrade security. Applying a standard ACL to OSPF to convert SNMP traps into BGP updates fails conceptually: ACLs on OSPF do not transmute SNMP into BGP. Relying on the ACL to encrypt SNMPv3 payloads so authPriv becomes unnecessary fails because ACLs filter packets; they do not provide SNMP cryptographic privacy. Exam caveat: an SNMP ACL that forgets the NMS source after a management-station renumbering looks like an SNMPv3 failure—verify source allow-lists when civic NMS addresses change. Operational check: define an ACL permitting approved NMS prefixes to SNMP, attach it to SNMP agent access configuration, deny others, and test polling/traps from allowed versus disallowed stations while confirming SNMPv3 authPriv remains enabled.