07-16-2019 10:53 PM - edited 02-21-2020 11:07 AM
Hi guys,
I'm just wondering if these statements are still correct. Could someone please review?
1.) When the switchport allows DHCP (ICMPv6, DHCPv6) before ISE authorization, the authorization result should not include a change of the VLAN for MAB clients. This is because there is no way to tell the client to restart the DHCP (SLAAC, stateful DHCPv6) process. After the VLAN change the client is most likely in the wrong IP context.
2.) Some MAB clients may work depending on the application implementation (e.g. Cisco lightweight APs continously restart the DHCP process during the discovery phase if no WLC is reachable)
3.) 802.1X enabled clients are typically not an issue for VLAN changes in low impact mode, because (most of them) are (re)starting DHCP if the 802.1X process is successfully finished (RADIUS ACCESS-ACCEPT).
==> The DHCP process is triggered by the client AFTER authorization
If network segmentation is required in combination with wired network access control the following options exist in combination with low impact mode allowing dynamic addresses before authorization:
Are my findings correct here?
Thank you!!!
07-17-2019 02:10 AM
07-17-2019 03:14 AM - edited 07-17-2019 03:16 AM
Hi Mohammed,
thanks for the feedback. Just one side note:
Of course dACLs are requiring TCAM. Cisco Catalyst 2960-X switches (SDM template “lanbase-routing”) provide a worst case maximum of 600 IPv4 ACEs for the whole switch / stack.
Rule of thumb is, that one line required one TCAM ACE space (some ACEs may be able to be aggregated using masks).
Just test it (at least I did it for the Cat2960-X platform)
Base situation: Port 1 of a switch is in shutdown state. Behind that port is an AP. Once authorized, it is assigned a dACL.
But let's start from the beginning... port 1 is shutdown:
sw2960x#show access-session interface gi1/0/1 details No sessions match supplied criteria. sw2960x#show ip access-lists interface gi1/0/1 sw2960x# sw2960x#show platform tcam utilization CAM Utilization for ASIC# 0 Max Used Masks/Values Masks/values Unicast mac addresses: 32988/32988 49/49 IPv4 IGMP groups + multicast routes: 1072/1072 2/2 IPv4 unicast directly-connected routes: 2048/2048 0/0 IPv4 unicast indirectly-connected routes: 1024/1024 34/34 IPv6 Multicast groups: 1072/1072 14/14 IPv6 unicast directly-connected routes: 2048/2048 0/0 IPv6 unicast indirectly-connected routes: 1024/1024 3/3 IPv4 policy based routing aces: 504/504 14/14 IPv4 qos aces: 504/504 59/59 IPv4 security aces: 600/600 114/114 IPv6 policy based routing aces: 20/20 8/8 IPv6 qos aces: 500/500 47/47 IPv6 security aces: 600/600 20/20 Note: Allocation of TCAM entries per feature uses a complex algorithm. The above information is meant to provide an abstract view of the current TCAM utilization
==> Used IPv4 ACEs in TCAM: 114
Now the port is put into the enabled state... let's wait for authorization
000193: Jul 17 11:59:31.075 MESZ: %AUTHMGR-5-START: Starting 'dot1x' for client (0000.5e00.5301) on Interface Gi1/0/1 AuditSessionID 0A6307040000005805010530 000194: Jul 17 11:59:31.075 MESZ: %AUTHMGR-5-START: Starting 'mab' for client (0000.5e00.5301) on Interface Gi1/0/1 AuditSessionID 0A6307040000005805010530 000195: Jul 17 11:59:31.630 MESZ: %AUTHMGR-5-SUCCESS: Authorization succeeded for client (0000.5e00.5301) on Interface Gi1/0/1 AuditSessionID 0A6307040000005805010530 sw2960x# sw2960x#show access-session interface gi1/0/1 details Interface: GigabitEthernet1/0/1 MAC Address: 0000.5e00.5301 IPv6 Address: xxxxxxxxxxxxxxxxxxxxx IPv4 Address: 192.168.0.1 User-Name: 00-00-5E-00-53-01 Status: Authorized Domain: DATA Oper host mode: single-host Oper control dir: both Session timeout: N/A Restart timeout: N/A Periodic Acct timeout: 172800s (local), Remaining: 172791s Session Uptime: 10s Common Session ID: 0A6307040000005805010530 Acct Session ID: 0x000000AE Handle: 0x79000006 Current Policy: BLABLUBB Server Policies: Idle timeout: 90 sec Vlan Group: Vlan: 10 Interface Template: AP ACS ACL: xACSACLx-IP-Cisco_APs-5a8dadf0 Method status list: Method State dot1x Running mab Authc Success sw2960x#show ip access-lists interface gi1/0/1 permit icmp host 192.168.0.1 any echo permit icmp host 192.168.0.1 any echo-reply permit icmp host 192.168.0.1 any time-exceeded permit icmp host 192.168.0.1 any unreachable permit udp host 192.168.0.1 eq bootpc any eq bootps permit udp host 192.168.0.1 any eq domain permit udp host 192.168.0.1 any range 5246 5247 permit tcp host 192.168.0.1 eq 22 any Extended IP access list Auth-Default-ACL-OPEN 10 permit ip any any sw2960x#show platform tcam utilization CAM Utilization for ASIC# 0 Max Used Masks/Values Masks/values Unicast mac addresses: 32988/32988 50/50 IPv4 IGMP groups + multicast routes: 1072/1072 2/2 IPv4 unicast directly-connected routes: 2048/2048 0/0 IPv4 unicast indirectly-connected routes: 1024/1024 34/34 IPv6 Multicast groups: 1072/1072 14/14 IPv6 unicast directly-connected routes: 2048/2048 0/0 IPv6 unicast indirectly-connected routes: 1024/1024 3/3 IPv4 policy based routing aces: 504/504 14/14 IPv4 qos aces: 504/504 59/59 IPv4 security aces: 600/600 121/121 IPv6 policy based routing aces: 20/20 8/8 IPv6 qos aces: 500/500 47/47 IPv6 security aces: 600/600 20/20 Note: Allocation of TCAM entries per feature uses a complex algorithm. The above information is meant to provide an abstract view of the current TCAM utilization
As seen in the outputs, the dACL has 8 lines (show ip access-list interface ...).
After authorization, the IPv4 ACE TCAM utilization is 121 (before authZ it was 114).
==> TCAM utilization increased by 7
The dACL has 8 lines? Why did the TCAM utilization increase by 7?
==> Because line 1 and 2 (echo / code 8; echo-reply / code 0) are aggregable into one entry: l4Destination value 0x00 / mask 0xF7
So from what I see, TCAM utilization is an potential issue for dACLs as well.
==> Are your experiences different on other platforms? (e.g. 3850, 9k)
Other topics here are stating, that dACLs are affecting TCAM usage as well:
https://community.cisco.com/t5/policy-and-access/dacls-and-tcam-ressources/td-p/2141450
https://community.cisco.com/t5/identity-services-engine-ise/dacl-with-over-100-lines/td-p/3574279
Do you have a documentation source?
07-17-2019 03:57 AM
07-17-2019 04:11 AM - edited 07-17-2019 04:13 AM
It utilizes TCAM per interface in "multi-auth" or "multi-domain" mode, because the source IPv4 address is rewritten by the IP device tracking feature. In single host mode, the source part of the ACL may remain "any" and therefore TCAM entries may be aggregated.
If desired I will show the complete output again with two AP ports with the same authorization profile.
But it's enough to say that:
assuming that all APs where authorized with the same dACL before I did the port shutdown (multi-domain host mode). There is no filter-ID or static ACL assignment on the ports.
However, I haven't found any document, describing the actual TCAM utilization by dACLs. So obviously, you observed something different than I did :)
Could it be that:
a) I'm doing something wrong
b) Different platforms behave in different ways
c) There is a documentation, describing the behavior of dACL TCAM usage
d) Bug?
P.S.: What's really funny about this is, that in the most current Cat2960X release, IPv6 "RADIUS assigned" ACLs are supported using "user ACLs" (not dACLs and filter-ids). Somehow this works completely different. Although the source portion of the ACL is rewritten to the IPv6 addresses of the actual client behind the switch port (derived by IPv6 device tracking), the TCAM utilization (IPv6 ACE) does not change whether the client has two, three, four etc. IPv6 addresses :)
But this is another story :)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide