Downloadable ACLs (dACLs) with Cisco ISE and 802.1X

Downloadable ACLs: What They Do and Why They Matter

Static access control on 802.1X switchports has a scalability problem. If every access port needs a permit/deny ACL — and each user group needs a different ACL — you either configure dozens of ACLs on every switch in the network (configuration sprawl, version control nightmare) or you accept that all users in the same VLAN get the same traffic rights (which undermines the value of identity-based access).

Downloadable ACLs (dACLs) solve this by moving the ACL definition to ISE. When a user authenticates, ISE returns a filter reference in the RADIUS Access-Accept. The switch downloads the actual ACL entries from ISE and applies them as a per-session policy on the port. When the session ends, the ACL is removed. No ACLs to maintain on the switch; no configuration drift across hundreds of access layer devices.

The mechanism works through two RADIUS attributes:

• Cisco-AVPair: ip:inacl#<seq>=<ace> — ISE sends the actual ACE entries inline in the RADIUS response. These are applied immediately, no separate download step.
• Filter-Id — ISE sends only the name of an ACL that is already defined on the switch. The switch applies its locally defined ACL with that name.

In practice, Cisco ISE uses the Cisco-AVPair inline method. The "downloadable" terminology refers to ISE pushing the ACL content — it is not a separate TFTP or HTTP download. The switch receives the ACE entries as RADIUS attributes and installs them per-session.

IOS XE Switch Requirements

dACLs require the switch to be running IP device tracking. Without device tracking, the switch cannot bind the ACL to the endpoint's IP address.

Global Configuration

aaa new-model

aaa authentication dot1x default group radius
aaa authorization network default group radius

radius server ISE-Primary
 address ipv4 10.0.0.10 auth-port 1812 acct-port 1813
 key ISEsecret123

aaa server radius dynamic-author
 client 10.0.0.10 server-key ISEsecret123
 auth-type any

dot1x system-auth-control

ip device tracking

The ip device tracking command enables the switch to track the IP address of authenticated endpoints. This is required for dACL binding — the switch needs the endpoint's IP address to apply an IP ACL to the correct traffic stream. In IOS XE 17.9.x, device tracking is typically enabled via SISF (Switch Integrated Security Features):

device-tracking tracking

Verify device tracking is active:

SW1# show device-tracking database

Binding Table has 12 entries, 12 dynamic (limit 200000)
Codes: L - Local, S - Static, ND - Neighbor Discovery, ARP - ARP, DHCP - DHCP,
       REMOTE - Other

   Network Layer Address            Link Layer Address Interface  vlan  prl age state Time left
L   10.0.10.55            c8d9.d2e1.1001       Gi1/0/1    10    100 0mn REACHABLE  329 s
L   10.0.10.56            0021.a0b3.3344       Gi1/0/2    10    100 0mn REACHABLE  285 s

If device tracking is not active, authenticated sessions will show dACL names in show authentication sessions detail but the ACL will not filter any traffic — the binding is missing.

Interface Configuration

interface GigabitEthernet1/0/1
 description Corporate Workstation
 switchport mode access
 switchport access vlan 10
 authentication host-mode multi-auth
 authentication order dot1x mab
 authentication priority dot1x mab
 authentication port-control auto
 authentication periodic
 authentication timer reauthenticate server
 dot1x pae authenticator
 mab
 spanning-tree portfast
 ip access-group ACL-DEFAULT in

The ip access-group ACL-DEFAULT in applies a static default ACL to the port in the unauthorized state. This ACL should permit only DHCP and DNS — enough for the device to get an IP address and reach a captive portal if web auth is configured. The dACL from ISE will override this ACL when the session authenticates.

Define the default ACL:

ip access-list extended ACL-DEFAULT
 10 permit udp any host 255.255.255.255 eq 67
 20 permit udp any any eq 68
 30 permit udp any any eq 53
 40 deny   ip any any

ISE Configuration

Step 1: Define the Downloadable ACL

Navigate to Policy > Policy Elements > Results > Authorization > Downloadable ACLs.

Click Add. Create a dACL for each access tier you need. For corporate employees with full internal access:

Name: Corp-Employees-Full-Access

DACL Content:

permit ip any any

For contractors with restricted access — permit access to specific application servers only:

Name: Contractors-Restricted

DACL Content:

permit tcp any 10.0.10.0 0.0.0.255 eq 443
permit tcp any 10.0.10.0 0.0.0.255 eq 80
permit tcp any 10.0.10.0 0.0.0.255 eq 22
permit udp any any eq 53
permit udp any host 10.0.0.10 eq 67
deny   ip any any

For guest users — internet access only, no internal resources:

Name: Guest-Internet-Only

DACL Content:

deny   ip any 10.0.0.0 0.255.255.255
deny   ip any 172.16.0.0 0.15.255.255
deny   ip any 192.168.0.0 0.0.255.255
permit tcp any any eq 80
permit tcp any any eq 443
permit tcp any any eq 53
permit udp any any eq 53
deny   ip any any

The dACL syntax uses standard Cisco extended ACL syntax. Do not include access-list names or sequence numbers in the DACL content field — ISE adds those automatically when it converts the DACL into RADIUS attributes. Use only permit/deny statements.

Step 2: Create Authorization Profiles Referencing the dACL

Navigate to Policy > Policy Elements > Results > Authorization > Authorization Profiles.

Profile: Corp-Employees-Profile

• Name: Corp-Employees-Profile
• Access Type: ACCESS_ACCEPT
• Common Tasks:
  • VLAN: 10
  • Downloadable ACL: Corp-Employees-Full-Access (select from dropdown)

Profile: Contractors-Profile

• Name: Contractors-Profile
• Access Type: ACCESS_ACCEPT
• Common Tasks:
  • VLAN: 30
  • Downloadable ACL: Contractors-Restricted

Profile: Guest-Profile

• Name: Guest-Profile
• Access Type: ACCESS_ACCEPT
• Common Tasks:
  • VLAN: 30
  • Downloadable ACL: Guest-Internet-Only

When you configure the Downloadable ACL in the Common Tasks section and save, ISE adds the cisco-av-pair attribute containing the ACL entries to the RADIUS Access-Accept. Click the RADIUS Attributes tab to see the full attribute set that will be sent.

Step 3: Assign Authorization Profiles in Policy Rules

Navigate to Policy > Policy Sets > [your 802.1X policy set] > Authorization Policy.

Configure rules mapping user groups to profiles:

Verifying dACL Application

Check the Authenticated Session

SW1# show authentication sessions interface GigabitEthernet1/0/1 detail

            Interface:  GigabitEthernet1/0/1
          MAC Address:  c8d9.d2e1.1001
         IPv6 Address:  Unknown
         IPv4 Address:  10.0.10.55
           User-Name:  DOMAIN\jsmith
              Status:  Authorized
              Domain:  DATA
      Oper host mode:  multi-auth
    Oper control dir:  both
     Session timeout:  3600s (server), Remaining: 3201s
  Common Session ID:  0A00630A00000001
    Acct Session ID:  0x00000001
             Handle:  0x1C000001
     Current Policy:  POLICY_Gi1/0/1

Local Policies:
        Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)

Server Policies:
            Vlan Group:  Vlan: 10
                  ACS ACL: xGENIEx0a00630a00000001-1-xGENIEx

Method status list:
       Method           State
       dot1x            Authc Success

The ACS ACL: xGENIEx0a00630a00000001-1-xGENIEx line under Server Policies confirms a dACL has been applied to this session. The ACL name is generated by IOS XE as a combination of the session ID and an index — this is the internal name for the per-session ACL.

Verify the ACL Contents

SW1# show ip access-lists interface GigabitEthernet1/0/1

Interface GigabitEthernet1/0/1 inbound:
  Extended IP access list xGENIEx0a00630a00000001-1-xGENIEx
      10 permit ip any any (235 matches)

This shows the actual ACE entries that ISE pushed to the switch. For a more restrictive dACL (the Contractors-Restricted profile):

SW1# show ip access-lists xGENIEx0a00630a00000002-1-xGENIEx

Extended IP access list xGENIEx0a00630a00000002-1-xGENIEx
    10 permit tcp any 10.0.10.0 0.0.0.255 eq 443 (12 matches)
    20 permit tcp any 10.0.10.0 0.0.0.255 eq 80 (0 matches)
    30 permit tcp any 10.0.10.0 0.0.0.255 eq 22 (0 matches)
    40 permit udp any any eq 53 (5 matches)
    50 permit udp any host 10.0.0.10 eq 67 (2 matches)
    60 deny   ip any any (3 matches)

The match counters confirm the ACL is active and processing traffic. If all counters are zero including the deny, the ACL is installed but no traffic is hitting it — check IP device tracking binding.

Verify Device Tracking Binding

SW1# show device-tracking database interface GigabitEthernet1/0/1

Binding Table has 1 entries, 1 dynamic (limit 200000)

   Network Layer Address            Link Layer Address Interface  vlan  prl age state Time left
L   10.0.10.55            c8d9.d2e1.1001       Gi1/0/1    10    100 0mn REACHABLE  415 s

The binding entry maps MAC address c8d9.d2e1.1001 to IP address 10.0.10.55 on GigabitEthernet1/0/1. The switch uses this binding to attach the dACL to the correct IP traffic stream. Without this entry, the dACL name appears in show authentication sessions detail but the ACL is not filtering traffic.

dACL Scope: Inbound Only

A critical operational constraint: dACLs on Cisco IOS XE switchports are applied inbound only (from the endpoint toward the network). Return traffic from servers to the endpoint is not filtered by the dACL. This is consistent with how access-layer ACLs are typically applied — filter traffic entering the network from the untrusted endpoint side, and trust that server-originated traffic is legitimately destined for authenticated users.

If you need bidirectional filtering, consider applying a VLAN ACL (VACL) on the data VLAN's SVI, or use ISE TrustSec SGT-based filtering. TrustSec integration is covered in Article 29 (Cisco TrustSec and SGTs: How They Integrate with 802.1X).

dACL Size and Complexity Limits

Cisco IOS XE has hardware limits on the number of ACEs that can be applied per interface. On Catalyst 9300 series hardware:

• Maximum ACEs per dACL: 256 (hardware table dependent)
• Maximum simultaneous dACLs: limited by TCAM availability

In multi-auth mode, each authenticated session on a port gets its own dACL instance. A port with 5 authenticated endpoints (lab bench or docking station scenario) will have 5 separate dACL instances consuming TCAM entries. Monitor TCAM utilization:

SW1# show platform resources

**State Acronym: H - High, M - Medium, L - Low, N - Normal**

Resource                       State   Current Usage/Max
                               -------  ----------------
DRAM                           N         7% (730/9175 MB)
IOMEM                          N         6% (18/296 MB)
TCAM                           N        18% (9408/51200 entries)

If TCAM utilization is high, simplify dACLs or consolidate endpoint groups to reduce the number of distinct dACL definitions being pushed per session.

CoA and dACL Updates

A key operational benefit of dACLs is that ISE can push a new dACL to an active session via CoA (Change of Authorization) without requiring a full reauthentication. This is used in posture-based access control: the endpoint authenticates, gets a restrictive dACL while posture assessment runs, and then ISE sends a CoA with an updated dACL when the endpoint passes posture.

The CoA workflow requires the aaa server radius dynamic-author configuration block covered in the global configuration section above. When ISE sends a CoA Reauthenticate request, the switch reauthenticates the session and the new authorization profile (with updated dACL) is applied.

Verify CoA receipt on the switch:

SW1# debug radius dynamic-author

CoA configuration and troubleshooting is covered in Article 19 (Change of Authorization (CoA) in 802.1X: How It Works and How to Configure It).

Troubleshooting

Symptom: dACL name appears in show authentication sessions detail under ACS ACL but traffic is not being filtered

Cause: IP device tracking is not active, or the endpoint's IP address is not in the device tracking database. The switch requires a MAC-to-IP binding to attach the dACL to the correct traffic stream. Without the binding, the ACL is installed in the session database but not applied to any interface ACL.

Fix: Verify device tracking:

SW1# show device-tracking database

If the endpoint's IP address is not present, check whether device-tracking tracking is configured globally. Also confirm the endpoint has obtained an IP address via DHCP — a device without an IP address cannot have a device tracking entry. If the endpoint uses a static IP, device tracking may not learn it automatically. In IOS XE 17.9.x, ensure DHCP snooping or ARP inspection is running on the VLAN to populate device tracking bindings for static IP hosts:

ip dhcp snooping vlan 10
ip arp inspection vlan 10

Symptom: ISE authorization succeeds but show authentication sessions detail shows no ACS ACL line

Cause: The authorization profile applied by ISE does not include a dACL. Either the wrong authorization rule is being matched, or the profile definition on ISE does not have the Downloadable ACL field populated.

Fix: In ISE, navigate to Operations > RADIUS > Live Logs and find the authentication event. Click the detail icon and scroll to the Authorization Policy section — confirm which authorization profile was applied. Then navigate to Policy > Policy Elements > Results > Authorization > Authorization Profiles and open that profile. Verify the Downloadable ACL field in Common Tasks is checked and references the correct DACL name. Also confirm the DACL name referenced in the profile matches a DACL that exists in Policy > Policy Elements > Results > Authorization > Downloadable ACLs.

Symptom: dACL is applied but allows traffic that should be denied (or vice versa)

Cause 1: The dACL ACE order is incorrect. Cisco ACLs are evaluated top-to-bottom and the first match wins. A broad permit ip any any before a deny statement means the deny is never reached.

Fix: In ISE, navigate to Policy > Policy Elements > Results > Authorization > Downloadable ACLs and edit the DACL. Review the ACE order. Place specific deny statements before broad permit statements. Save and test — either trigger a reauthentication or send a CoA from ISE.

Cause 2: The dACL is applied inbound only. Traffic from servers to the endpoint bypasses the dACL. If the intent is to block return traffic, the dACL cannot accomplish this alone.

Fix: Apply VLAN-level filtering using VLAN access maps (VACLs) on the SVI for the data VLAN to filter bidirectional traffic:

ip access-list extended VACL-CONTRACTOR-BLOCK
 10 deny ip 10.0.10.0 0.0.0.255 10.0.10.0 0.0.0.255

vlan access-map CONTRACTOR-MAP 10
 match ip address VACL-CONTRACTOR-BLOCK
 action drop
vlan access-map CONTRACTOR-MAP 20
 action forward

vlan filter CONTRACTOR-MAP vlan-list 30

Note that VACLs are blunt instruments — they apply to all traffic in the VLAN, not per-session. For per-session bidirectional filtering, evaluate TrustSec SGT-based policy.

Symptom: After ISE sends a CoA to update the dACL, the old dACL is still showing on the switch

Cause: The CoA Reauthentication is failing silently. The switch may not be accepting the CoA request due to a configuration mismatch on the aaa server radius dynamic-author block, or the CoA source IP does not match the configured client.

Fix: Verify the dynamic author configuration:

SW1# show aaa server radius dynamic-author

Dynamic author clients:
  Client: 10.0.0.10, Server key: configured
  Message-Authenticator Attribute: Use if present

The client IP must match the ISE PSN node sending the CoA. If ISE has multiple PSN nodes, each must be listed as a client. Also verify the server-key matches ISEsecret123 exactly (case-sensitive). Test CoA connectivity from ISE by navigating to Operations > Troubleshoot > Diagnostic Tools > RADIUS Authentication Troubleshooting and sending a test CoA. Article 24 (dACL Not Applying Correctly in 802.1X: Troubleshooting Downloadable ACLs) covers dACL-specific troubleshooting in depth.

What's Next

Article 17 — 802.1X with IP Phones: Configuring Multi-Domain Authentication on Cisco IOS XE: The most common access-layer topology in enterprise campus networks puts a Cisco IP Phone between the switch and a PC workstation. Article 17 covers the full configuration required to authenticate both devices independently using Multi-Domain Authentication (MDA), with ISE policies for both voice and data domains.