Posts tagged ‘switching’

June 27, 2011

ACLs Supported on 3560 & 3750 Switches – Part II (VLAN Maps)

by costiser

This is the second part of a long post about ACL types that are supported on 3560 & 3750 series switches. If you missed the first part, take a look here:

ACLs Supported on 3560 & 3750 Switches – Part I (Port ACL and Router ACL)

In this post we will discuss about the VLAN ACLs also known as VACL or VLAN Maps.

June 26, 2011

ACLs Supported on 3560 & 3750 Switches – Part I (Port ACL & Router ACL)

by costiser

After a nice vacation, here I come again with a new post, this time about several ACL types that are supported on 3560 and 3750 series switches.

As you can see in the above chart, there are 3 types of ACLs supported on these switches:

  • Port ACLs
  • Router ACLs
  • VLAN ACLs (VLAN Maps)

Let’s take them one by one.

1.Port ACLs

Port ACLs are ACLs that are applied to Layer 2 interfaces on a switch.
Port ACLs are supported only on physical interfaces (not on EtherChannel interfaces) and can be applied only in the inbound direction.
For example, if you apply a port ACL to a trunk port, the ACL filters traffic on all VLANs present on the trunk port.
If you apply a port ACL to a port with voice VLAN, the ACL filters traffic on both data and voice VLANs.

YOu should have in mind that there are more access-lists that can be used as Port ACL. Here is how you can use them:

Numbered Standard IP ACL (ACL numbers 1-99, 1300-1999)

(config)# access-list 5 deny host
(config)# access-list 5 permit any

Numbered Extended IP ACL (ACL numbers 100-199, 2000-2699)

(config)# access-list 105 deny tcp eq telnet
(config)# access-list 105 deny udp
(config)# access-list 105 permit ip any any

Named Standard and Extended ACLs

(config)# ip access-list standard Stnd_ACL
(config-ext-nacl)# permit
(config)# ip access-list extended Extd_ACL
(config-ext-nacl)# deny tcp eq telnet
(config-ext-nacl)# deny udp
(config-ext-nacl)# permit ip any any

Named MAC Extended ACLs
You can filter non-IPv4 traffic on a VLAN (VLAN Maps) or on a Layer 2 interface (Port ACL) by using MAC addresses and named MAC extended ACLs.
The procedure is similar to that of configuring other extended named ACLs.
– You cannot apply named MAC extended ACLs to Layer 3 interfaces.
– You cannot use mac access-group command on EtherChannel ports

(config)# mac access-list extended ACL_MAC
(config-ext-macl)# permit any host 00c0.00a0.03fa netbios
(config-ext-macl)# deny any any 0x4321 0

(config)# interface gigabitethernet1/0/2
(config-if)# mac access-group ACL_MAC in

2. Router ACLs

There are not so many things to be said about the Router ACLs. Take a look to the above section and you’ll see how to create standard and extended, numbered and named ACLs.

The important differences that you need to remember are: Router ACLs control traffic that is routed between VLANs (SVIs) or L3 interfaces and they may be applied in both direction (inbound and outbound).


The last section, VLAN ACLs, will be discussed in next post:

ACLs Supported on 3560 & 3750 Switches – Part II (VLAN Maps)

May 23, 2011

Subtle difference for PORTFAST & BPDUFILTER used together globally or at interface-level

by costiser

Portfast + bpdufilter (used together) can be enabled globally or at interface level:


(config)#  spanning-tree portfast bpdufilter default

At interface level:

(config)#  interface x/x
(config-if)#  spanning-tree portfast
(config-if)#  spanning-tree bpdufilter enable

Although the first impression is that the only difference is the global or per-interface effect, this is not entirely true and another subtle and important difference is described below.

By default, a port configured with portfast is still sending out BPDUs. If you want portfast-enabled ports to stop sending BPDUs you may rush to use command (config-if)# spanning-tree bpdufilter enable on the same interface.
While this gives you what you want (don’t send BPDUs on portfast interfaces), you have the following problem: you disable completely STP on that port, meaning that you stop both sending and receiving BPDUs. This is NOT SAFE as it may result in STP loops (in case you connect a BPDU-enabled device on that port).

A better option (and here it comes up the subtle difference that I talked about) is to enable bpdufilter globally for all portfast-enabled ports: (config)# spanning-tree portfast bpdufilter default.
This command stops, as well, sending BPDUs on the portfast interfaces, but in case a BPDU is received on that port, it will resume STP operations on it, thus preventing STP loops. If a BPDU is received, that port loses its portfast status immediatelly and starts following the STP rules/states.