Access Security Guide K/KA/KB.15.15

Table 34 Effect of the above ACL on inbound IPv4 traffic in the assigned VLAN (continued)
ActionLine #
A TCP packet from SA 10.28.18.100 with a DA of 10.28.237.1 will be permitted (forwarded).
Since no earlier ACEs in the list have filtered TCP packets from 10.28.18.100 and destined for
30
10.28.237.1, the switch will use this ACE to evaluate such packets. Any packets that meet this
criteria will be forwarded. (Any packets that do not meet this TCP source-destination criteria are not
affected by this ACE.)
A TCP packet from source address 10.28.18.100 to any destination address will be denied (dropped).
Since, in this example, the intent is to block TCP traffic from 10.28.18.100 to any destination except
40
the destination stated in the ACE at line 30, this ACE must follow the ACE at line 30. (If their relative
positions were exchanged, all TCP traffic from 10.28.18.100 would be dropped, including the
traffic for the 10.28.18.1 destination.)
Any packet from any IPv4 SA to any IPv4 DA will be permitted (forwarded). The only traffic to reach
this ACE will be IPv4 packets not specifically permitted or denied by the earlier ACEs.
50
The Implicit Deny is a function the switch automatically adds as the last action in all ACLs. It denies
(drops) any IPv4 traffic from any source to any destination that has not found a match with earlier
n/a
entries in the ACL. In this example, the ACE at line 50 permits (forwards) any IPv4 traffic not already
permitted or denied by the earlier entries in the list, so there is no traffic remaining for action by the
Implicit Deny function.
Marks the end of the ACL.exit
Allowing for the Implied Deny function
In any ACL having one or more ACEs there will always be a packet match. This is because the
switch automatically applies an Implicit Deny as the last ACE in any ACL. This function is not visible
in ACL listings, but is always present, see Figure 241 (page 330). This means that if you configure
the switch to use an ACL for filtering either inbound or outbound IPv4 traffic on a VLAN, any
packets not specifically permitted or denied by the explicit entries you create will be denied by
the Implicit Deny action. If you want to preempt the Implicit Deny (so that IPv4 traffic not specifically
addressed by earlier ACEs in a given ACL will be permitted), insert an explicit permit any (for
standard ACLs) or permit ip any any (for extended ACLs) as the last explicit ACE in the ACL.
A configured ACL has no effect until you apply it to an interface
The switch stores ACLs in the configuration file. Thus, until you actually assign an ACL to an interface,
it is present in the configuration, but not used (and does not use any of the monitored resources,
see "Monitored Resources" in the Management and Configuration Guide for your switch.)
You can assign an ACL name or number to an interface even if the ACL does not exist in the switch
configuration
In this case, if you subsequently create an ACL with that name or number, the switch automatically
applies each ACE as soon as you enter it in the running-config file. Similarly, if you modify an
existing ACE in an ACL you already applied to an interface, the switch automatically implements
the new ACE as soon as you enter it. The switch allows up to 2048 ACLs each for IPv4 and
determines the total from the number of unique ACL names in the configuration.For example, if
you configure two ACLs, but assign only one of them to a VLAN, the ACL total is two, for the two
unique ACL names. If you then assign the name of a nonexistent ACL to a VLAN, the new ACL
total is three, because the switch now has three unique ACL names in its configuration.
(RADIUS-based ACL resources are drawn from the IPv4 allocation).
(For a summary of ACL resource limits, see the appendix covering scalability in the latest
Management and Configuration Guide for your switch.)
Overview 331