ITC/3AV WIKI

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== CONFIGURING AND ASSIGNING AN IPV4 ACL ======

===== General steps for implementing ACLs =====

1. Configure one or more ACLs.

This creates and stores the ACL(s) in the switch configuration.

2. Assign an ACL.

This step uses one of the following applications to assign the ACL to an interface:

- VACL (any IPv4 traffic entering the switch on a given VLAN)

- Static Port ACL (any IPv4 traffic entering the switch on a given port, port list, or static trunk)

===== Options for permit/deny policies =====

The permit or deny policy for IPv4 traffic you want to filter can be based on source address alone, or on source address plus other IPv4 factor

**1. Standard ACL:** Uses only a packet's source IPv4 address as a criterion for permitting or denying the packet. For a standard ACL ID, use either a unique numeric string in the range of 1-99 or a unique name string of up to 64 alphanumeric characters.

**2. Extended ACL:** Offers the following criteria as options for permitting or denying a packet:

- source IPv4 address

- destination IPv4 address

- IPv4 protocol options:

//Any IPv4 traffic//

//Any traffic of a specific IPv4 protocol type (0-255)//

//Any TCP traffic (only) for a specific TCP port or range of ports, including optional use of TCP control bits or control of connection (established) traffic based on whether the initial request should be allowed//

//Any UDP traffic (only) or UDP traffic for a specific UDP port//

//Any ICMP traffic (only) or ICMP traffic of a specific type and code//

//Any IGMP traffic (only) or IGMP traffic of a specific type//

//Any of the above with specific precedence and/or ToS settings (Applies to the HP Switch 2620 and 2920-series only)//

For an extended ACL ID, use either a unique number in the range of 100-199 or a unique name string of up to 64 alphanumeric characters.

Carefully plan ACL applications before configuring specific ACLs.

===== ACL configuration structure =====

After you enter an ACL command, you may want to inspect the resulting configuration. This is especially true where you are entering multiple ACEs into an ACL. Also, it is helpful to understand the configuration structure when using the following information.

The basic ACL structure includes four elements:

1. ACL identity and type: This identifies the ACL as standard or extended and shows the ACL name or number.

2. Optional remark entries.

3. One or more deny/permit list entries (ACEs): One entry per line.

{{:aruba_networks:switch:acl_1_-_hvillanueva.png?1100|}}

4. Implicit Deny:Where an ACL is in use, it denies any packets that do not have a match with the ACEs explicitly configured in the list. The Implicit Deny does not appear in ACL configuration listings, but always functions when the switch uses an ACL to filter packets. (You cannot delete the Implicit Deny, but you cansupersede it with a permit any or permit ip any any statement.)

==== Standard ACL structure ====

Individual ACEs in a standard ACL include only a permit/deny statement, the source addressing, and an optional log command (available with "deny" or "permit" statements).

The general structure for a standard ACL

{{:aruba_networks:switch:acl_2_-_hvillanueva.png?600|}}

For example, A displayed standard ACL configuration with two ACEs shows how to interpret the entries in a standard ACL.

**A displayed standard ACL configuration with two ACEs**

{{:aruba_networks:switch:acl_3_-_hvillanueva.png?600|}}

==== Extended ACL configuration structure ====

Individual ACEs in an extended ACL include:

- A permit/deny statement

- Source and destination IPv4 addressing

- Choice of IPv4 criteria, including optional precedence and ToS

Optional ACL log command (for deny or permit entries)

- Optional remark statements

**General structure options for an extended ACL**

{{:aruba_networks:switch:acl_4_-_hvillanueva.png?600|}}

**Displayed extended ACL configuration**

{{:aruba_networks:switch:acl_5_-_hvillanueva.png?600|}}

===== ACL configuration factors =====

==== The sequence of entries in an ACL is significant ====

When the switch uses an ACL to determine whether to permit or deny a packet, it compares the packet to the criteria specified in the individual ACEs in the ACL, beginning with the first ACE in the list and proceeding sequentially until a match is found. When a match is found, the switch applies the indicated action (permit or deny) to the packet. This is significant because, once a match is found for a packet, subsequent ACEs in the same ACL will not be applied to that packet, regardless of whether they match the packet.

For example, suppose that you have applied the ACL shown in to inbound IPv4 traffic on VLAN 1 (the default VLAN):

**A standard ACL that permits all IPv4 traffic not implicitly denied**

{{:aruba_networks:switch:acl_6_-_hvillanueva.png?600|}}

**Effect of the above ACL on inbound IPv4 traffic in the assigned VLAN**

{{:aruba_networks:switch:acl_7_-_hvillanueva.png|}}

==== 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. 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.)

===== Using the CLI to create an ACL =====

You can use either the switch CLI or an offline text editor to create an ACL. This section describes the CLI method, which is recommended for creating short ACLs.

==== Inserting or adding an ACE to an ACL ====

These rules apply to all IPv4 ACEs you create or edit using the CLI:

- Named IPv4 ACLs: Add an ACE to the end of a named ACE by using the ip access-list command to enter the Named ACL (nacl) context and entering the ACE without the sequence number.

For example, if you wanted to add a "permit" ACL at the end of a list named "List-1" to allow traffic from the device at 10.10.10.100:

{{:aruba_networks:switch:acl_8_-_hvillanueva.png|}}

===== Using CIDR notation to enter the IPv4 ACL mask =====

Use CIDR notation to enter ACL masks. The switch interprets the bits specified with CIDR notation as the address bits in an ACL and the corresponding address bits in a packet that must match. The switch then converts the mask to inverse notation for ACL use.

**Examples of CIDR notation for masks**

{{:aruba_networks:switch:acl_9_-_hvillanueva.png|}}

 --- //[[ing.hvillanueva@gmail.com|Humberto Villanueva]] 2020/11/10 01:41//