A wastewater treatment plant renumbers interfaces after a dual-stack redesign and finds an IPv6 traffic filter no longer affects camera traffic. What should engineers verify first about the filter?
Select an answer to reveal the explanation.
Short Explanation
After a renumber, the filter can be a perfect list taped to the wrong door. Confirm it's applied on the interface (and direction) where the camera IPv6 packets actually show up.
Full Explanation
After a wastewater treatment plant renumbers interfaces in a dual-stack redesign and an IPv6 traffic filter no longer affects camera traffic, engineers should first verify that the IPv6 traffic filter is applied to the correct current interface and direction carrying the camera IPv6 flows. Renumbering and re-cabling often leave a correct ACL applied to an old interface name or the wrong direction. The correct first check works because ACL content can be perfect while the attachment point no longer sits on the camera path. Checking that the IPv6 ACL is stored only in NVRAM under an IPv4 access-class name fails as a first-line explanation because the usual failure after renumber is mis-application, not NVRAM naming mysticism. Deleting MPLS L3VPN route targets so IPv6 ACLs activate campus-wide fails conceptually: route targets control VPN route import/export, not whether an interface IPv6 traffic-filter is attached. Disabling aaa new-model to force IPv6 filters onto all interfaces fails because AAA activation is unrelated to IPv6 ACL interface binding. Exam caveat: dual-stack redesigns can move cameras to a new SVI/VLAN while the filter remains on the old L3 interface—confirm both Layer-2 attachment and Layer-3 filter placement. Operational check: trace the camera IPv6 path, show ipv6 interface / running-config for traffic-filter statements on the current interface, fix direction/interface as needed, and retest with IPv6 ACL counters on live camera flows.