A large university is moving its dorm switches to IBNS 2.0. The team builds a class map that matches MAB sessions, a policy map reacting to session-started and authentication-failure events, and a service template carrying the data VLAN and a device ACL. Which description correctly divides the work on the access port between the policy map and the service template?
Select an answer to reveal the explanation.
Short Explanation
You've got one object that decides and one object that delivers, and mixing them up is a classic IBNS 2.0 slip. The policy map is the state machine reacting to authentication events, while the service template is a bundle of attributes pushed onto the port. Keep those two straight and the switch configuration writes itself.
Full Explanation
Under IBNS 2.0 the switch separates decision logic from delivery. The policy map type control subscriber is a state machine: class maps decide which sessions it applies to, and inside it numbered events such as session-started, authentication-success and authentication-failure trigger actions like authenticate, terminate or activate service-template. The service template is a named container for authorization attributes such as data VLAN, voice VLAN, dACL, SGT or a WebAuth redirect, and nothing reaches the port until a policy map action activates it. Treating the service template as the matching object confuses it with the class map, which is built from match rules such as method mab or method dot1x. Believing the policy map itself stores the VLAN and ACL reverses the two roles, because a policy map holds commands and timers rather than attributes. Casting the class map as the attribute store also fails, since a class map cannot carry an authorization result. Exam caveat: a service template can also be activated as a fallback, for example on authorization failure. A practical check is to run show access-session interface detail and confirm which template and attributes landed after the session authenticated.