ip access-list standard <name-str>

Places the CLI in the "Named ACL" (nacl) context specified by the <name-str> alphanumeric identifier. This enables entry of individual ACEs in the specified ACL. If the ACL does not already exist, this command creates it.

<name–str>: Specifies an identifier for the ACL. Consists of an alphanumeric string of up to 64 case-sensitive characters. Including spaces in the string requires that you enclose the string in single or double quotes. For example: Accounting ACL.

<deny | permit>

<any | host <SA> | SA <mask | SA/ mask-length>> [log]

Executing this command appends the ACE to the end of the list of ACEs in the current ACL. In the default ACL configuration, ACEs are automatically assigned consecutive sequence numbers in increments of 10 and can be renumbered using resequence (See Resequencing the ACEs in an ACL.)

	NOTE: To insert a new ACE between two existing ACEs, precede deny or permit with an appropriate sequence number. See Inserting an ACE in an existing ACL.

<deny | permit>

For named ACLs, used in the "Named ACL" ( nacl) context to configure an ACE. Specifies whether the ACE denies or permits a packet matching the criteria in the ACE, as described below.

<any | host <SA> | SA <mask | SA/ mask-length>>

Defines the source IPv4 address (SA) a packet must carry for a match with the ACE.

• any

  Allows IPv4 packets from any SA.

• host <SA>

  Specifies only packets having <SA> as the source. Use this criterion when you want to match the IPv4 packets from a single source address.

• SA <mask> or SA /mask–length

  Specifies packets received from either a subnet or a group of IPv4 addresses. The mask format can be in either dotted-decimal format or CIDR format (number of significant bits). See How an ACE uses a mask to screen packets for matches.

• Mask Application

  The mask is applied to the IPv4 address in the ACE to define which bits in a packet's SA must exactly match the SA configured in the ACE and which bits need not match. For example: 10.10.10.1/24 and 10.10.10.1 0.0.0.255 both define any address in the range of 10.10.10.(1 - 255).

  	NOTE: Specifying a group of contiguous addresses may require more than one ACE. For more on how masks operate, see How an ACE uses a mask to screen packets for matches.

• [log]

  This option generates an ACL log message if:

  • The action is deny.

  • There is a match.

  • ACL logging is enabled on the switch. See Enabling ACL logging on the switch for more details.

  • Use the debug command to direct ACL logging output to the current console session and to a Syslog server. Note that you must also use the logging <ip-addr>command to specify the addresses of Syslog servers to which you want log messages sent. See also Enabling ACL logging on the switch.

access-list <1–99> <deny | permit>

<any | host <SA> | SA <mask | SA/ mask-length>> [ log]

Appends an ACE to the end of the list of ACEs in the current IPv4 standard, numbered ACL. If the ACL does not already exist, creates both the ACL and its first ACE. In the default configuration, ACEs are automatically assigned consecutive sequence numbers in increments of 10 and can be renumbered using resequence, see Resequencing the ACEs in an ACL.

	NOTE: To insert a new ACE between two existing ACEs in a standard, numbered ACL: Use ip access list extended <1 - 99> to open the ACL as a named ACL. Enter the desired sequence number along with the ACE keywords and variables you want. (After a numbered ACL has been created, it can be managed as either a named or numbered ACL.)

<1–99>

Specifies the ACL identifier as a number. The switch interprets an ACL with a value in this range as a standard ACL (which filters all IPv4 traffic on the basis of SA). To create a standard access list with an alphanumeric name ( name-str) instead of a number, see Configuring named, standard ACLs.

<deny | permit>

Specifies whether the ACE denies or permits a packet matching the criteria in the ACE, as described next.

<any | host <SA> | SA <mask | SA/ mask-length>>

Defines the source IPv4 address (SA) a packet must carry for a match with the ACE.

• any - Allows IPv4 packets from any SA.

• host <SA> - Specifies only packets having <SA> as the source. Use this criterion when you want to match only the IPv4 packets from a single SA.

SA <mask> or SA /mask–length - Specifies packets received from an SA, where the SA is either a subnet or a group of IPv4 addresses. The mask format can be in either dotted-decimal format or CIDR format (number of significant bits). See How an ACE uses a mask to screen packets for matches.

SA Mask application: The mask is applied to the SA in the ACE to define which bits in a packet's SA must exactly match the SA configured in the ACL and which bits need not match.

Example

10.10.10.1/24 and 10.10.10.1 0.0.0.255 both define any address in the range of 10.10.10.(1 - 255).

	NOTE: Specifying a group of contiguous addresses may require more than one ACE. For more on how masks operate in ACLs, see How an ACE uses a mask to screen packets for matches.

[log]

This option can be used after the SA to generate an Event Log message if:

• The action is deny or permit.

• There is a match.

• ACL logging is enabled.

(See Enabling ACL logging on the switch.)

ip access–list extended <name-str>

Places the CLI in the "Named ACL" (nacl) context specified by the <name-str> alphanumeric identifier. This enables entry of individual ACEs in the specified ACL. If the ACL does not already exist, this command creates it.

<name-str>

Specifies an alphanumeric identifier for the ACL. Consists of an alphanumeric string of up to 64 case-sensitive characters. Including spaces in the string requires that you enclose the string in single or double quotes. For example:accounting ACL. You can also use this command to access an existing, numbered ACL. SeeUsing the CLI to edit ACLs.

<deny | permit> <ip | ip-protocol | ip-protocol-nbr>

<any | host <SA> | SA <mask | SA/ mask-length>>

<any | host <DA> | DA <mask | DA/ mask-length>>

[precedence] [tos] [log]

Appends an ACE to the end of the list of ACEs in the current ACL. In the default configuration, ACEs are automatically assigned consecutive sequence numbers in increments of 10 and can be renumbered using resequence, see Resequencing the ACEs in an ACL).

Note: To insert a new ACE between two existing ACEs in an extended, named ACL, precede deny or permitwith an appropriate sequence number along with the ACE keywords and variables you want. See Inserting an ACE in an existing ACL.

For a match to occur, a packet must have the source and destination addressing criteria specified in the ACE, as well as:

• the protocol-specific criteria configured in the ACE, including any included, optional elements (described later in this section)

• any (optional) precedence and ToS settings configured in the ACE

<deny | permit>

For named ACLs, these keywords are used in the "Named ACL" (nacl) context to specify whether the ACE denies or permits a packet matching the criteria in the ACE, as described below.

<ip | ip-protocol|ip-protocol-nbr>

Used after deny or permit to specify the packet protocol type required for a match. An extended ACL must include one of the following:

• ip —any IPv4 packet.

• ip-protocol — any one of the following IPv4 protocol names:

  ip-in-ip ipv6-in-ipgre es pah

  ospfpim vrrp sctp tcp*

  udp* icmp* igmp*

• ip-protocol-nbr — the protocol number of an IPv4 packet type, such as "8" for Exterior Gateway Protocol or 121 for Simple Message Protocol. (For a listing of IPv4 protocol numbers and their corresponding protocol names, see theIANA "Protocol Number Assignment Services" at www.iana.com.) (Range: 0 - 255)

*For TCP, UDP, ICMP, and IGMP, additional criteria can be specified, as described on pages Including options for TCP and UDP traffic in extended ACLs through Controlling IGMP traffic in extended ACLs.

<any | host <SA> | SA <mask | SA/ mask–length>

This is the first instance of IPv4 addressing in an extended ACE. It follows the protocol specifier and defines the source address (SA) a packet must carry for a match with the ACE.

• any

  Allows IPv4 packets from any SA.

• host<SA>

  Specifies only packets having a single address as the SA. Use this criterion when you want to match only the IPv4 packets from a single SA.

• SA <mask> or SA/mask-length

  Specifies packets received from an SA, where the SA is either a subnet or a group of addresses. The mask can be in either dotted-decimal format or CIDR format (number of significant bits). See How an ACE uses a mask to screen packets for matches.

  SA Mask application

  The mask is applied to the SA in the ACL to define which bits in a packet's SA must exactly match the SA configured in the ACL and which bits need not match.

  Example

  10.10.10.1/24 and 10.10.10.1 0.0.0.255 both define any address in the range of 10.10.10.(1 - 255).

  Note: Specifying a group of contiguous addresses may require more than one ACE. For more on how masks operate in ACLs, see How an ACE uses a mask to screen packets for matches.

<any | host <DA> | DA <mask | DA/ mask-length>>

This is the second instance of IPv4 addressing in an extended ACE. It follows the first (SA) instance, described earlier, and defines the destination address (DA) that a packet must carry in order to have a match with the ACE.

• any

  Allows routed IPv4 packets to any DA.

• host<DA>

  Specifies only packets having DAas the destination address. Use this criterion when you want to match only the IPv4 packets for a single DA.

• DA/mask-length or DA<mask>

  Specifies packets intended for a destination address, where the address is either a subnet or a group of addresses. The mask format can be in either dotted-decimal format or CIDR format (number of significant bits). See How an ACE uses a mask to screen packets for matches.

  DA Mask application

  The mask is applied to the DA in the ACL to define which bits in a packet's DA must exactly match the DA configured in the ACL and which bits need not match.

[ precedence <0 – 7 ] | [precedence–name>]

This option can be used after the DA to cause the ACE to match packets with the specified IP precedence value. Values can be entered as the following IP precedence numbers or alphanumeric names:

0 or routine

1 " priority

2 " immediate

3 " flash

4 " flash-override

5 " critical

6 " internet (for internetwork control)

7 " network (for network control)

Note: The precedence criteria described in this section are applied in addition to any other selection criteria configured in the same ACE.

[tos <tos-setting>]

This option can be used after the DA to cause the ACE to match packets with the specified Type-of-Service (ToS) setting. ToS values can be entered as the following numeric settings or, in the case of 0, 2, 4, and 8, as alphanumeric names:

0 or normal

2 " max-reliability

4 " max-throughput

6

8 " minimize-delay

Note: The ToS criteria in this section are applied in addition to any other criteria configured in the same ACE.

[ log ]

This option can be used after the DA to generate an Event Log message if:

• The action is deny. Not applicable to permit.

• There is a match.

• ACL logging is enabled. See Enabling ACL logging on the switch.

<deny | permit> tcp

<SA> [ comparison-operator <tcp-src-port>]

<DA> [comparison-operator <tcp-dest-port>]

[established]

[ack] [fin] [ rst ] [syn]

<deny | permit> udp

<SA> [comparison-operator <udp-src-port>]

<DA> [comparison-operator <udp-dest-port>]

In an extended ACL using either tcp or udp as the packet protocol type, you can optionally use TCP or UDP source and/or destination port numbers or ranges of numbers to further define the criteria for a match.

#deny tcp host 10.20.10.17 eq 23 host 10.20.10.155 established
#permit tcp host 10.10.10.100 host 10.20.10.17 eq telnet
#deny udp 10.30.10.1/24 host 10.20.10.17 range 161 162
comparison-operator <tcp/udp–src–port>
range <start-port-nbr><end-port-nbr>

For a match with the ACE entry, the TCP or UDP source-port number a packet must be in the range of<start-port-nbr> to <end-port-nbr>

Configuring ACEs that use the range comparison operator with extended ACLs

The port range comparison operator is handled by two different mechanisms in the switch. The switch first attempts to use the TCAM directly to install the port range using a key and mask operation within a single TCAM entry, but if this is not possible then the port range comparison operator must use one of the dedicated h/w range registers.

There are 14 hardware range registers per V1 module ( 60 for a V2 module) that can be used for port range ACEs. Once all the range registers are used up, no furtherport ranges that require use of the hardware range register (such as, ones that cannot be matched by TCAM alone) can be added and the switch returns an Unable to create access control entry message when modifying ACLs.

Use the following techniques to express port ranges with minimal use of the dedicated h/w application registers.

• Using a TDP/UDP port range comparison operator

  Using the optional TCP or UDP port comparison operator 'RANGE' in extended ACL ACE or Class Filter statements might require that you use a hardware Application Port Range.

  The switch first performs three tests to determine if the range of ports can be met using "Don't Care" masking instead of a hardware Application Port Range. There are three parts to the test:

  1. The lowest N bits of binary representation of the start value are all zeroes.

  2. The lowest N bits of binary representation of the end value are all ones.

  3. The upper 16-N bits of both values are the same.

  If the range fails any of the three tests, a hardware Application Port Range is used.

  Port Range "Don't Care" masking is similar to IP address subnet masking. For example, an IPv4 subnet of 10.0.0.0 255.255.255.240, which represents a range of IP addresses from 10.0.0.240 through 10.0.0.255. When looking at the bottom byte of the address, the start value is 240 or binary 11110000. The end value is 255 or binary 11111111. These two values pass all three tests: the start value lower 4 bits are all zero, the end value lower 4 bits are all ones, and the upper bits are the same. Therefore, the range can be expressed in binary as 1111****, where * means "Don't Care".

  To avoid using a hardware Application Port Range, break a range into a series of sub-ranges that:

  • Are a power of two in length, to meet the first two tests.

  • Start on a multiple of that same power of two, but do not cross a larger power of two, to meet the last test.

  To do this:

  1. Find the largest power of two that is evenly divisible into the start value.

  2. Make the end value the start value plus the power of two minus one.

  3. Repeat using the end value plus one as the new start value until the entire range is covered.

  Examples

  To configure a 301 port destination TCP or UDP range from 6400 to 6700:

  PERMIT TCP ANY ANY RANGE 6400 6700
  

  This can be converted to 4 maskable sub-ranges and a single port:

  6400-6655 = length 256 (2**8) starting on a multiple of 256 (25 * 256)
  6656-6687 = length 32 (2**5) starting on a multiple of 256 (26 * 256)
  6688-6695 = length 8 (2**3) starting on a multiple of 8 (836 * 8)
  6696-6699 = length 4 (2**2) starting on a multiple of 4 (1674 * 4)
  6700
  
  PERMIT TCP ANY ANY RANGE 6400 6655
  PERMIT TCP ANY ANY RANGE 6656 6687
  PERMIT TCP ANY ANY RANGE 6688 6695
  PERMIT TCP ANY ANY RANGE 6696 6699
  PERMIT TCP ANY ANY EQ 6700
  

  Another more complicated example of a 301 port range from 6300 to 6600 can be expressed as 6 maskable sub-ranges and a single port:

  6300-6303 = length 4
  6304-6335 = length 16
  6336-6399 = length 64
  6400-6527 = length 128
  6528-6591 = length 64
  6592-6599 = length 8
  6600
  

  To configure a range 32 port range from 4080 to 4111, you must break it into two sub-ranges, even though is it an even power of two (32) in

  length because it crosses a higher power of two (4096 = 2**12):

  4080-4095 = length of 16 starting on a multiple of 16 (255 * 16)
  4096-4111 = length of 16 starting on a multiple of 16 (256 * 16)
  

• Using TDP/UDP port GT and LT comparison operators

  Using the optional TCP or UDP port Comparison Operators 'GT' and 'LT' in extended ACL ACE or Class Filter statements might also require that you use a hardware Application Port Range.

  To minimize the use of hardware Application Port Ranges, convert these operators into a range of ports, and apply the range technique described in the preceding section.

  • Convert 'GT PORT' to 'RANGE PORT+1 65535'.

    For example, 'GT 4000' is the same as 'RANGE 4001 65535'.

  • Convert 'LT PORT' to 'RANGE 0 PORT-1 65535'.

    For example, 'GE 4000' is the same as 'RANGE 0 3999'.

• Using the TDP/UDP port NE comparison operator

  The optional TCP or UDP port Comparison Operator 'NE' in ACL ACE or Class Filter statements always requires that you use a hardware Application Port Range. In this case, there is no technique to avoid using a hardware Application Port Range.

	NOTE: A port range that starts with an odd number always requires a hardware range register due to the TCAM mask operation. A port range that ends with an even number also always requires a hardware range. A configured port range can be referenced by multiple ACEs. However be aware that if a single port range that uses a hardware range register is applied as both a source and destination range within the list of ACEs, then two port range registers are actually used by this single port range.

To specify a TCP or UDP source port number in an ACE:

1. Select a comparison operator from the following list.

2. Enter the port number or a well-known port name.

   Comparison operators

   • eq <tcp/udp-port-nbr>

     "Equal To"; to have a match with the ACE entry, the TCP or UDP source port number in a packet must be equal to <tcp/udp-port-nbr>.

   • gt <tcp/udp-port-nbr>

     "Greater Than"; to have a match with the ACE entry, the TCP or UDP source port number in a packet must be greater than <tcp/udp-port-nbr>.

   • lt <tcp/udp-port-nbr>

     "Less Than"; to have a match with the ACE entry, the TCP or UDP source port number in a packet must be less than <tcp/udp-port-nbr>.

   • neq <tcp/udp-port-nbr>

     "Not Equal"; to have a match with the ACE entry, the TCP or UDP source port number in a packet must not be equal to <tcp/udp-port-nbr>.

   • range <start-port-nbr> <end-port-nbr>

     For a match with the ACE entry, the TCP or UDP source-port number in a packet must be in the range <start-port-nbr> <end-port-nbr>.

Port number or well-known port name

Use the TCP or UDP port number required by your application.

The switch also accepts these well-known TCP or UDP port names as an alternative to their port numbers:

• TCP — bgp, dns, ftp, http, imap4, ldap, nntp, pop2, pop3, smtp, ssl, telnet

• UDP — bootpc, bootps, dns, ntp, radius, radius-old, rip, snmp, snmp-trap, tftp

To list the above names, press the [Shift] [ ?] key combination after entering an operator. For a comprehensive listing of port numbers, visit www.iana.org/assignments/port-numbers.

comparison-operator <tcp-dest-port> established

comparison-operator <udp-dest-port>

This option, if used, is entered immediately after the <DA> entry.

To specify a TCP or UDP port number:

1. Select a comparison operator.

2. Enter the port number or a well-known port name.

Comparison operators and well-known port names

These are the same as are used with the TCP/UDP source-port options, and are listed earlier in this command description.

[established]

This option applies only where TCP is the configured protocol type. It blocks the synchronizing packet associated with establishing a TCP connection in one direction on a VLAN while allowing all other IPv4 traffic for the same type of connection in the opposite direction. For example, a Telnet connect requires TCP traffic to move both ways between a host and the target device. Simply applying a denyto inbound Telnet traffic on a VLAN would prevent Telnet sessions in either direction because responses to outbound requests would be blocked. However, by using the established option, inbound Telnet traffic arriving in response to outbound Telnet requests would be permitted, but inbound Telnet traffic trying to establish a connection would be denied.

TCP control bits

In a given ACE for filtering TCP traffic you can configure one or more of these options:

• [ack] — Acknowledgement.

• [fin] — Sender finished.

• [rst] — Connection reset.

• [syn] — TCP control bit: sequence number synchronize.

For more on using TCP control bits, see RFC 793.

<deny | permit> icmp <SA> <DA> [icmp-type [ icmp-code]]

<deny | permit> tcp icmp <SA> <DA> [ icmp-type-name]

In an extended ACL using icmp as the packet protocol type (see above), you can optionally specify an individual ICMP packet type or packet type/code pair to further define the criteria for a match. This option, if used, is entered immediately after the destination address (DA) entry. The following example shows two ACEs entered in a Named ACL context:

Example

#permit icmp any any host-unknown

#permit icmp any any 3 7

[icmp-type [ icmp-code]]

This option identifies an individual ICMP packet type as criteria for permitting or denying that type of ICMP traffic in an ACE.

• icmp–type - This value is in the range of 0 - 255 and corresponds to an ICMP packet type.

• icmp–code - This value is in the range of 0 - 255 and corresponds to an ICMP code for an ICMP packet type.

[icmp–type–name]

For more information on ICMP type names, visit the Internet Assigned Numbers Authority (IANA) website at www.iana.com. click on "Protocol Number Assignment Services", and then go to the selections under "Internet Control Message Protocol (ICMP) Parameters".

Syntax option

[icmp-type [ icmp-code]]

These name options are an alternative to the methodology described above. For more information, visit the IANA website cited above.

• administratively-prohibitednet-tos-unreachable

• alternate-addressnet-unreachable

• conversion-errornetwork-unknown

• dod-host-prohibitedno-room-for-option

• dod-net-prohibitedoption-missing

• echopacket-too-big

• echo-replyparameter-problem

• general-parameter-problemport-unreachable

• host-isolatedprecedence-unreachable

• host-precedence-unreachableprotocol-unreachable

• host-redirectreassembly-timeout

• host-tos-redirectredirect

• host-tos-unreachablerouter-advertisement

• host-unknownrouter-solicitation

• host-unreachablesource-quench

• information-replysource-route-failed

• information-requesttime-exceeded

• mask-replytimestamp-reply

• mask-requesttimestamp-request

• mobile-redirecttraceroute

• net-redirectttl-exceeded

• net-tos-redirectunreachable

<permit | deny> igmp SA DA [ igmp-type ]

In an extended ACL using igmp as the packet protocol type, you can optionally specify an individual IGMP packet type to further define the criteria for a match. This option, if used, is entered immediately after the destination addressing entry. The following example shows an IGMP ACE entered in the Named ACL context:

HP Switch(config-ext-nacl)# permit igmp any any host-query

[ igmp-type ]

The complete list of IGMP packet-type options includes:

dvmrptracemtrace-request

host-queryv2-host-reportv3-host-report

host-reportv2-host-leave

pimmtrace-reply

For more information on IGMP packet types, visit the Internet Assigned Numbers Authority (IANA) website at www.iana.com.); select "Protocol Number Assignment Services", and then go to the selections under "Internet Group Management Protocol (IGMP) Type Numbers".

Suppose that you want to implement these policies on a switch configured for IPv4 routing and membership in VLANs 10, 20, and 30:

1. Permit Telnet traffic from 10.10.10.44 to 10.10.20.78, deny all other IPv4 traffic from network 10.10.10.0 (VLAN 10) to 10.10.20.0 (VLAN 20), and permit all other IPv4 traffic from any source to any destination. (See "A" in An extended ACL, below.)

2. Permit FTP traffic from 10.10.20.100 (on VLAN 20) to 10.10.30.55 (on VLAN 30). Deny FTP traffic from other hosts on network10.10.20.0 to any destination, but permit all other IPv4 traffic.

access-list<100-199> <deny | permit> <ip | ip-protocol | ip-protocol-nbr>

<any | host <SA> | SA/mask-length | SA <mask>>

If the ACL does not already exist, this command creates the specified ACL and its first ACE. If the ACL already exists, the new ACE is appended to the end of the configured list of explicit ACEs. In the default configuration, the ACEs in an ACL will automatically be assigned consecutive sequence numbers in increments of 10 and can be renumbered with resequence see Resequencing the ACEs in an ACL.

	NOTE: To insert a new ACE between two existing ACEs in an extended, numbered ACL: Use ip access list extended <100 - 199> to open the ACL as a named ACL. Enter the desired sequence number along with the ACE statement you want.

For a match to occur, a packet must have the source and destination addressing criteria specified in the ACE, as well as:

• The protocol-specific criteria configured in the ACE, including any included, optional elements (described later in this section.)

• Any (optional) precedence and ToS settings configured in the ACE.

<100-199>

Specifies the ACL ID number. The switch interprets a numeric ACL with a value in this range as an extended ACL.

<deny | permit>

Specifies whether to deny ( drop) or permit (forward) a packet that matches the criteria specified in the ACE, as described below.

<ip | ip-protocol | ip-protocol-nbr>

Specifies the packet protocol type required for a match. An extended ACL must include one of the following:

• ip — any IPv4 packet.

• ip-protocol — any one of the following IPv4 protocol names:

  • ospfpim vrrp sctp tcp*

  • ip-in-ip ipv6-in-ipgre esp ah

  • udp*icmp* igmp*

  * For TCP, UDP, ICMP, and IGMP, additional criteria can be specified, as described later in this section.

• ip-protocol-nbr — the protocol number of an IPv4 packet type, such as "8" for Exterior Gateway Protocol or 121 for Simple Message Protocol. (For a listing of IPv4 protocol numbers and their corresponding protocol names, see the IANA "Protocol Number Assignment Services" at www.iana.com.) (Range: 0 - 255)

<any | host <SA> | SA/mask-length | SA <mask>>

In an extended ACL, this parameter defines the source address (SA) that a packet must carry in order to have a match with the ACE.

• any

  Specifies all inbound IPv4 packets.

• host <SA>

  Specifies only inbound IPv4 packets from a single address. Use this option when you want to match only the IPv4 packets from a single source address.

• SA/mask-length or SA <mask>

  Specifies packets received from an SA, where the SA is either a subnet or a group of IPv4 addresses. The mask can be in either dotted-decimal format or CIDR format with the number of significant bits. See How an ACE uses a mask to screen packets for matches.

  SA mask application

  The mask is applied to the SA in the ACL to define which bits in a packet's source SA must exactly match the address configured in the ACL and which bits need not match.

  Example

  10.10.10.1/24 and 10.10.10.1 0.0.0.255 both define any IPv4 address in the range of 10.10.10.(1-255).

  	NOTE: Specifying a group of contiguous IPv4 addresses may require more than one ACE. For more on how masks operate in ACLs, see How an ACE uses a mask to screen packets for matches.

Syntax

<any | host <SA> | SA/mask-length | SA <mask>>

This is the second instance of addressing in an extended ACE. It follows the first (SA) instance, described earlier, and defines the destination address (DA) that a packet must carry in order to have a match with the ACE. The options are the same as shown for <SA>.

• any

  Allows routed IPv4 packets to any DA.

• host <DA>

  Specifies only the packets having DAas the destination address. Use this criterion when you want to match only the IPv4 packets for a single DA.

• DA/mask-length or DA <mask>

  Specifies packets intended for a destination address, where the address is either a subnet or a group of IPv4 addresses. The mask format can be in either dotted-decimal format or CIDR format (number of significant bits). See How an ACE uses a mask to screen packets for matches.

  DA Mask application

  The mask is applied to the DA in the ACL to define which bits in a packet's DA must exactly match the DA configured in the ACL and which bits need not match. See also the above example and note.

Syntax

[ precedence <0 - 7 | precedence-name> ]

This option causes the ACE to match packets with the specified IP precedence value. Values can be entered as the following IP precedence numbers or alphanumeric names:

0 or routine

1 " priority

2 " immediate

3 " flash

4 "flash-override

5 " critical

6 " internet (for internetwork control)

7 " network (for network control)

	NOTE: the precedence criteria described in this section are applied in addition to any other selection criteria configured in the same ACE.

[ tos ]

This option can be used after the DA to cause the ACE to match packets with the specified Type-of-Service (ToS) setting. ToS values can be entered as the following numeric settings or, in the case of 0, 2, 4, and 8, as alphanumeric names:

0 or normal

2 " max-reliability

4 " max-throughput

6

8 " minimize-delay

	NOTE: The ToS criteria in this section are applied in addition to any other criteria configured in the same ACE.

[log]

Optional; generates an Event Log message if:

• The action is deny. This option is not configurable for Permit.

• There is a match.

• ACL logging is enabled on the switch. See Enabling ACL logging on the switch for details.

access-list <100 - 199> <deny | permit> <tcp | udp>

<SA> [comparison-operator <tcp/udp-src-port>]

<DA> [comparison-operator <tcp-dest-port>] [established]

<DA> [comparison-operator <udp-dest-port>]

This source-port and destination-port TCP/UDP criteria is identical to the criteria described for TCP/UDP use in named, extended ACLs. See Including options for TCP and UDP traffic in extended ACLs.

access–list <100 - 199> <deny | permit> icmp <SA> <DA>

[ [ icmp-type [ icmp-code]] | [icmp-type-name] ]

The ICMP "type" and "code" criteria are identical to the criteria described for ICMP in named, extended ACLs.

access-list <100 - 199>

<deny | permit> igmp <src-ip> <dest-ip> [ igmp-type]

The IGMP "type" criteria is identical to the criteria described for IGMP in named, extended ACLs. See Controlling IGMP traffic in extended ACLs.