IPv4 Counter Operation with Multiple Interface Assignments

Where the same IPv4 ACL is assigned to multiple interfaces as a VLAN ACL (VACL) or port ACL (PACL), the switch maintains a separate instance of ACE counters for each interface assignment. Thus, when there is a match with traffic on one of the ACL's VACL- or PACL -assigned interfaces, only the ACE counter in the affected instance of the ACL is incremented. However, if an ACL has multiple assignments as an RACL, then a match with an ACE in any RACL instance of the ACL increments that same counter on all RACL-assigned instances of that ACL. (The ACE counters for VACL and PACL instances of an ACL are not affected by counter activity in RACL instances of the same ACL.)

For example, suppose that an ACL named "Test-1" is configured as shown in ACL "Test-1" and interface assignment commands to block Telnet access to a server at 10.10.20.12 on VLAN 20, and that the Test-1 ACL is assigned to VLANs as follows:

  • VLAN 20: VACL

  • VLAN 50: RACL

  • VLAN 70: RACL

ACL "Test-1" and interface assignment commands
Using the same ACL for VACL and RACL applications

In the above case:

  • Matches with ACEs 10 or 20 that originate on VLAN 20 increment only the counters for the instances of these two ACEs in the Test-1 VACL assignment on VLAN 20. The same counters in the instances of ACL Test-1 assigned to VLANs 50 and 70 are not be incremented.

  • Any Telnet requests to 10.10.20.12 that originate on VLANs 50 or 70 are filtered by instances of Test-1 assigned as RACLs, and increment the counters for ACE 10 on both RACL instances of the Test-1 ACL.

A device at 10.10.20.4 on VLAN 20 attempting to ping and Telnet to 10.10.20.2 is filtered through the VACL instance of the "Test-1" ACL on VLAN 20 and results in the following:

Ping and telnet filtered by the assignment of "Test-1" as a VACL on VLAN 20
  • Drop all GVRP advertisements received on the port.

  • Disable the port from sending advertisements of existing GVRP-created VLANs on the switch.

For more information, see "GVRP" in the advanced traffic management guide.

If you disable the use of dynamic VLANs in an authentication session using the no aaa port-access gvrp-vlans command, client sessions that were authenticated with a dynamic VLAN continue and are not deauthenticated.

Note: This behavior differs from how static VLAN assignment is handled in an authentication session. If you remove the configuration of the static VLAN used to create a temporary client session, the 802.1X, MAC, or Web authenticated client is deauthenticated.

However, if a RADIUS-configured dynamic VLAN used for an authentication session is deleted from the switch through normal GVRP operation (for example, if no GVRP advertisements for the VLAN are received on any switch port), authenticated clients using this VLAN are deauthenticated.

NOTE:

Any port VLAN-ID changes made on 802.1X-aware ports during an 802.1X-authenticated session do not take effect until the session ends.

With GVRP enabled, a temporary, untagged static VLAN assignment created on a port by 802.1X authentication is advertised as an existing VLAN. If this temporary VLAN assignment causes the switch to disable a configured (untagged) static VLAN assignment on the port, then the disabled VLAN assignment is not advertised. When the 802.1X session ends, the switch:
  • Eliminates and ceases to advertise the temporary VLAN assignment.

  • Re-activates and resumes advertising the temporarily disabled VLAN assignment.