Re: Low impact mode, allowed DHCP and VLAN change

Johannes Luther · ‎07-16-2019

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:

VLAN change is possible for 802.1X enabled clients
VLAN change might be possible (most likely not) for MAB clients depending on the OS/application
Segmentation may be achived by:
- VLAN change in different VNs / VRFs / VPNs (for clients which can deal with VLAN changes)
- dACLs (caution: ingress only, TCAM!!!!)
- SGT (security group tags in "classical" network) / enforced by l3 switches or supported firewalls
- SGT (scalable group tags in "SD" networks) / enforced by leaf switches (egress) or supported firewalls

Are my findings correct here?

Thank you!!!

Mohammed al Baqari · ‎07-17-2019

Hi,

Your 1, 2, 3 findings are correct. Regarding segmentation:

* dACL isn't a problem for TCAM. This is a problem with Filter-ID
* I suggest to use SGT (security) to allow trust-sec and microsegmentation
which provides easier manageability using identities with ISE integration
(it prevents against L2 attacks as well if you access switches support SGT
segmen.)
* For SDA networks, I didn't test it. Not yet convinced in the concept of
LISP and VXLAN in campus to replace spanning tree. It looks complicated and
I don't see how it resolve problems.

***** remember to rate useful posts.

Johannes Luther · ‎07-17-2019

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?

Mohammed al Baqari · ‎07-17-2019

You are right that it utilizes TCAM ACEs but not per interface. I mean that if you same dACL on two interfaces the TCAM utilization will still be 8. While with Filter-ID is 16. Try on your 2960

Johannes Luther · ‎07-17-2019

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:

If I shutdown one port with an AP, the TCAM IPv4 ACE utilization is 114 (as shown in the previous outputs)
If I shutdown two ports with APs, the TCAM IPv4 ACE utilization is 107
If I shutdown three ports with APs, the TCAM IPv4 ACE utilization is 100
....

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 :)