802.1q tag on access switchport

[MATTHIAS SCHAERER]

What does a switch (2960 to 6500) do when it receives frame with an 802.1q header (all bits set to 0) on an interface configured with switchport mode access?

Any hint is welcome. Regards mat

[milan.kulik · Accepted solution]

Hi,

if it's tagged for a VLAN to which the interface is assigned to, it should accept it.

In other cases it should drop it.

HTH,

Milan

[cadet alain · Accepted solution]

Hi Milan,

If it is an access port it should not receive a tagged frame, isn't it? except for the voice vlan but then this is technically a trunk port even it is configured as an access.

Can you confirm/infirm my reasoning?

Regards.

Alain.

[CSCO11832637 · Accepted solution]

Hi,

from cisco Doc:

"If an access port receives a packet with an 802.1Q tag in the header other than the access VLAN value,

that port drops the packet without learning its MAC source address."

I think you should go for a  trunk link as alain proposed.

Regards,

Guillaume

[Peter Paluch · Accepted solution]

Gentlemen,

To my knowledge, an access port also accepts tagged frames if they conform to one of the following criteria:

• Either the VLAN ID in the tag is set to 0 which means that this is a priority-tagged frame (802.1p)
• Or the VLAN ID in the tag is equal to the access VLAN of the port

I had this confirmed on 2950 Catalyst switches, and I presume it was also true for 3550. I am not sure about higher Catalysts, though.

The newer 2960 Catalysts actually introduce another prerequisite: a switchport must be configured with a voice VLAN to accept any tagged frames whatsoever. If there is no voice VLAN configured on an access port, all tagged frames, including those whose VID is 0 or the port's access VLAN, will be dropped unconditionally. This is probably a security feature to disallow injection of tagged frames into the network on ports where no tagging is expected at all.

Best regards,

Peter

[Giuseppe Larosa · Accepted solution]

Hello Peter,

>> This is probably a security feature to disallow injection of tagged frames into the network on ports where no tagging is expected at all.

yes a countermeasure to dual vlan hopping attack where the external vlan tag is equal to the access vlan id on the port.

I would add that older switches like a C5500 CATOS accept tagged frames with any vlan-id defined on the switch allowing for single vlan hopping attack.

an 802.1Q haeder with all zeroes would mean vlan-id = 0 802.1P bits =0 and canonical format indicator = 0 => ethernet so yes it would be a good match for voice-vlan 802.1p command on the switchport

I was used to the behaviour you have described in first two bullets.

Hope to help

Giuseppe

[Peter Paluch]

Giuseppe,

Thank you very much for sharing that knowledge. I did not know about the Cat5500 CATOS switches. A pretty dull attack, actually

Best regards,

Peter

[rsimoni · Accepted solution]

Hi all,

Peter is perfectly right, however there is still something to add on the topic.

How a switchport should behave is defined in "IEEE Standards for Local and

Metropolitan Area Networks: Virtual Bridged Local Area Networks" Std 802.1Q-1998 which in Annex D defines Trunk, Access and Hybrid links.

To summarize in 2 lines (even though the interpretation of the standard might be controversial) according to the standards if the port is an access link only untagged frames should be accepted while ANY type of tagged frame should be dropped, including the ones matching the vlan ID.

The only case where tagged frames (matching VLAN IDs) are accepted is when the port is a hybrid link, which is a link that can receive both tagged and untagged traffic. An access port with voice vlan configured is a hybrid link as it can receive both untagged traffic (from PC) and tagged traffic from phones.

That leads that one between the Cat2950 and the Cat2960 is not behaving correctly as they show different behaviors. The answer is that the correct behavior is the Cat2960 as on access ports all tagged frames should be dropped no matter what. The reason is that the dropping/forwarding decision is taken at port ASIC level and the one on old Cat2950 was not able to drop frames with tag matching the allowed vlans.

New port ASICs have this capability and the same behavior is seen on other Catalysts switches (personally tested on 3560,4500) even though other behavior can still be seen (again it depends on port ASIC, so some model can have ASICs not able to do so).

To conclude this long story since what the standard defines for hybrid links can be somehow considered a security breach (personally I cannot figure out why) as allowing tagged frames matching vlan ID can be perceived as a potential issue Cisco is working on an enhancement feature by which an interface k n o b  (this word gets censored for some reason) will be available to expressely decide the port behavior regarding tagged frames whether drop or allow them. However before that will be available port ASIC behaviour must be consistent across all platforms, and this is what Cisco is doing right now.

regards,

Riccardo

[MATTHIAS SCHAERER]

Thanks to everybody for this overwhelming number of enlightening answers. They all match my observations and explain the behavior as well as the reasons for the intentions in the implementation.

The situation where I observed the behavior was in an industrial network containing Siemens PLC communicating to a Simatic Manager. I assume that the PLC intended to use 802.1p without having any knowledge about the VLAN topology. A hint in the internet brought up the voice vlan idea which sounded a bit weird firstly but with all your explanations above it makes very much sense now.

I could imagine other situations with Windows XP and higher using QoS on an Ethernet V2 NIC.

Thanks again, hopefully other people can use this post as well.

Mat

[Peter Paluch]

Riccardo,

Thanks for that wonderful answer and explanation. Rated as deserved.

Best regards,

Peter

[rsimoni]

Peter,

I am glad you appreciated 

Riccardo

[sivam siva]

@Peter Paluch  @rsimoni  @Giuseppe Larosa

Can anyone explain my below doubt?

If I have configured trunk with native VLAN 2, what if trunk port receives a frame that is tagged with VLAN 2? 

(Normally that port should expect to receive VLAN 2 frame as untagged), so my doubt is will it accept and process that frame in vlan2?.

Thanks 

Siva

[yan.rai@gmail.com]

Yep

[Arad]

agreed with Milan,
As Cisco document if a non-802.1q enabled device or an access port receives an 802.1q farme, the tag is ignored and the packet is switched at L2 as a standard Ethernet frame. this allows for the placement of the unmanaged switches and so on. but if the tagged packet is received on access port other than the current access VLAN value so the packet is dropped.