A bank is rolling out BYOD onboarding on Catalyst access switches, with the ISE internal CA issuing device certificates. Unauthenticated laptops must still resolve DNS and reach the BYOD portal, traffic headed to the ISE server stays outside the redirect match, and the switch must intercept browser requests on standard web ports. Which switch-side redirect configuration should be deployed for BYOD onboarding?
Select an answer to reveal the explanation.
Short Explanation
Redirecting has two halves, and the switch needs both of them. The redirect ACL decides which flows get sent to the portal, while the dACL keeps enough reachability for the laptop to find it, so you'll need both working. Call the redirect ACL the turnstile and the dACL the hallway lighting that leads to the portal.
Full Explanation
On IOS-based switches, central web auth interception only works for browser traffic on the standard web ports, and the switch must run its HTTP services for the interception path to fire at all. The redirect ACL is evaluated first: deny entries for traffic such as flows to the ISE server and DNS keep that traffic from being redirected, while permitted matching web traffic is redirected to the BYOD portal. The dACL delivered with the authorization profile keeps the unauthenticated client able to resolve the portal name and open its page over HTTPS. Relying on an ACL name match alone fails because the HTTP server feature is never enabled, so no interception happens. Matching ISE-bound traffic fails because the portal's own traffic is pulled into the redirect loop and onboarding cannot complete. A dACL limited to DHCP fails because the browser has no name resolution and no path to the portal. Exam caveat: interception triggers only on the standard web ports, so traffic on other ports passes without redirect. Practical check: run show ip http server status and show authentication sessions to confirm the services are up and the redirect ACL is attached.