A university runs BYOD on a Catalyst access switch and a 9800 WLC. Students authenticate with 802.1X and should be sent to the ISE onboarding page as soon as they join, while DHCP, DNS and portal traffic must still pass before authorization completes. Which redirect ACL design works on both the switch and the controller?
Select an answer to reveal the explanation.
Short Explanation
Think of the redirect ACL as a detour sign: it lets DHCP, DNS, and the ISE portal through, then steers other HTTP traffic to onboarding. That way, you can reach the portal while unauthenticated and still get redirected when you try another site.
Full Explanation
The working design permits DHCP, DNS, and ISE portal traffic before authorization, while redirecting other HTTP requests to onboarding. These exceptions let a newly connected student obtain network configuration, resolve names, and reach the portal; other HTTP traffic triggers the intended redirect. The same permit-and-redirect logic must use the supported redirect ACL mechanism on both the Catalyst switch and the 9800 WLC. Permitting DHCP and DNS but redirecting all HTTP, including ISE portal requests, can redirect the portal request away from its intended destination. Permitting DHCP, DNS, and portal traffic but waiting to redirect HTTP until 802.1X completes delays onboarding, contrary to the requirement to redirect students as soon as they join. Applying the permits and HTTP redirect on the WLC but not the switch leaves wired switch sessions without the required redirect behavior, so the design does not work on both platforms. Exam caveat: redirect ACL syntax and portal-destination handling vary by platform and software release; equivalent-looking ACLs may not be supported identically. Practical check: test an unauthenticated client on each access platform and verify DHCP, DNS, and ISE portal reachability, plus redirection of an unrelated HTTP request.