Cisco ENNA 300-445: ISE Policy Reorder, CoA That Fails on Old Switches and a Mixed SGT Estate

ISE Policy Reorder, CoA That Fails on Old Switches and a Mixed SGT Estate

A regional hospital runs 6,400 switch ports across 210 Catalyst 9200 and 40 Catalyst 2960X switches. ISE 3.2 provides 802.1X EAP-TLS for 5,000 managed workstations, MAB for 900 printers and badge readers, and a CWA redirect for unknown devices. Every port is configured with authentication host-mode multi-auth, plus both mab and dot1x. After a policy-set reorder last Tuesday, 300 printers began landing in the Unknown authorization profile with a dACL of deny ip any any. CoA requests from ISE to the 2960X switches time out, while the 9200s accept them. Clinical staff have started power-cycling printers to force a new session. Security also wants SGT-based segmentation between medical devices, guest and corporate traffic; the 9200s support SGACL enforcement in hardware, the 2960X do not. Downtime is not permitted and change control requires a per-floor rollback plan.

1. Why do 300 printers land in the Unknown profile with a deny-all dACL, and what would you check first? Give the troubleshooting sequence.

Read the worked answer

Start with a live session rather than with the policy, because the symptom has two plausible causes and they are distinguished quickly.

Step 1: show authentication sessions interface Gi1/0/5 details on a port with a failing printer. Confirm which method was used (MAB versus dot1x), which authorization profile was applied and which dACL name the switch received. If the session shows the printer authenticating by MAB but authorised by the Unknown profile, the problem is policy matching. If the session shows the printer authorised with the correct profile name but traffic is still dropped, the problem is the dACL itself.

Step 2: In ISE Live Logs, read the matched policy set and authorization rule for that MAC. A policy-set reorder typically moves the Unknown or default set above the MAB printer set, so printers never reach the rule that assigns the printer profile. Restore the order so that a specific, condition-based set is evaluated before the catch-all.

Step 3: Check the endpoint identity group and profiling policy. If SNMP or DHCP probes to the printer VLAN stopped, the device no longer profiles as a printer and the condition Device Type equals Printer no longer matches.

Step 4: Check that the dACL name in the authorization result actually exists on the 2960X. A downloadable ACL or named ACL that is referenced but not present on the switch results in a deny-all default, which is exactly the symptom seen here. This is common when the 9200s received the ACL definition from a template and the 2960X were never updated.

Rollback per floor: restore the previous policy-set order, confirm with one printer session per floor, then check the remaining ports.

2. Why do CoA requests time out for the 40 Catalyst 2960X switches but succeed for the 9200s, and what configuration or platform constraints would you check?

Read the worked answer

CoA is not part of RADIUS authentication. ISE sends a separate Disconnect or CoA-Request from the PSN to the network access device on UDP port 3799, and the switch must be configured to accept it. Authentication succeeding proves nothing about CoA.

Checklist:

aaa server radius dynamic-author on the 2960X: the client entry must list the PSN IP addresses and the correct server key. If the key differs from the ISE network-device entry, the CoA is silently dropped.
The ISE network device object must use the IP address that is reachable from the PSN. If the 2960X are managed by a loopback or an out-of-band VLAN that is not the address registered in ISE, the CoA goes to the wrong address or is sourced from an interface the switch does not recognise.
Confirm the CoA source port and any ACL or firewall between the PSN and the management network permits UDP 3799 in both directions.
Platform and image: CoA support varies by 2960X software image. Verify the running image and feature set rather than assuming parity with the 9200.
On the switch, debug radius during a test CoA from ISE shows whether the packet arrives and why it is rejected. On ISE, the CoA audit log shows the timeout source.

Do not work around this with shorter reauthentication timers. A 300-printer floor with a one-hour reauth timer means a policy fix takes an hour to apply; CoA is what makes the segmentation operationally usable.

3. How would you design SGT segmentation across a mixed 9200 and 2960X estate without downtime, and what are the limits of the approach?

Read the worked answer

The constraint is that an SGT is a tag carried in the packet, and enforcement happens where an SGACL is applied. A 2960X cannot enforce SGACLs and, in practice, does not support inline tagging of traffic from its access ports. Design around that rather than pretending the estate is uniform.

Practical design:

Enforce at the 9200 distribution layer, which every inter-VLAN flow crosses. Medical-device, corporate and guest SGTs are defined in ISE, propagated to the fabric or to the Catalyst switches by SXP or static IP-to-SGT mapping, and SGACLs are applied on the 9200 SVIs.
For closets on 2960X, map whole VLANs or subnets to an SGT at the first 9200 that sees the traffic. This is the key limitation: every device in a 2960X closet inherits the same SGT because the tag is assigned by subnet, not by port. If a closet mixes a medical device and a guest port, you cannot separate them with SGT alone.
Where a 2960X closet must separate device classes, use VLAN segmentation plus a dACL from ISE for that closet, and plan the hardware refresh as the long-term path.

Sequencing to avoid downtime: monitor mode first, so ISE logs what would be blocked without enforcing; review the flows for two weeks; then enforce one floor at a time with the 9200 SGACL policy set. Keep an explicit permit rule for clinical device-to-server flows that the monitoring phase showed to be essential, and make the per-floor rollback a single SGACL policy change rather than a VLAN redesign.