Tagged frames on access ports

Answered Question
Dec 2nd, 2008

Can someone definitively tell me what a catalyst 4507 will do with tagged frames that it receives on an access port?

My old 5500 that I just replaced seems to have been forwarding such traffic unadulterated to the destination mac address but the 4507 I just installed doesn't seem to be.

I'm aware of security implications about allowing hosts to add vlan tags to their traffic but this is a lab environment where the behavior of the old switch was of great benefit in our situation.

Will the 4507 drop tagged frames that it receives on a non trunk port?

Thank you in advance.

I have this problem too.
0 votes
Correct Answer by Giuseppe Larosa about 8 years 1 month ago

hello Elliott,

>> the endpoints are tagging some of their outbound frames with their own vlan information. In other words, it's not a vlan that exists on the cisco switch. It's just an identifier that the receiving endpoint will recognize and process independently of IP communications

this is not permitted anymore. You understand the disruptive potential of what you have described above in the network of a bank.

You should define all the vlans that you are going to use only at layer2 (no ip services over them)

make all the ports trunk ports

int gx/y

switchport

switchport trunk enc dot1q

switchport trunk native vlan 193

switchport mode trunk

switchport nonegotiate

the default is that all L2 vlans are permitted

vlan 193 has also L3 services but this is not a problem

this should work

the vlans have to be defined at layer2 (so I hope)

Hope to help

Giuseppe

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
ralphcarter Tue, 12/02/2008 - 20:48

Do you mean tagged frames comming from a server with vlan tagging conencted to a switchport? or 2 switches connected together, one side dot1q mode trunk and the other side mode access port?

I dont believe your trunk will form. Are you sure you didnt have a config like

switchport mode trunk

switchport trunk encap dot1q

switchport access vlan xx

where you thought it was an access port?

epeeler Wed, 12/03/2008 - 06:44

These are end point devices that are tagging frames in order to communicate with each other at layer two apart from the regular IP/Ethernet traffic. Again, it's a lab environment and this has nothing to do with trunking.

I have another 5500 in the lab and connecting the endpoints back into that allows the tagged frames to be passed among them so there's definitely a behavioral difference between the two switches.

If there's a way for me to enable this work on the new switch then that would be great to know but if not, it would be nice to have a definitive answer so that I can tell the lab folks that their kludge is not going to work anymore.

ganeshhiyer Tue, 12/02/2008 - 21:44

Hi

I suppose If tagged frame from a server come in catalyst switch access portit will drop.

tagging of frame are done by switch vlan database file to which Vlan the port are assigned...

Ganesh.H

glen.grant Wed, 12/03/2008 - 02:04

Unless the port is setup as a trunk the switch would not know what to do with a tagged frame . The 5500 should have been no different on a access port .

Giuseppe Larosa Wed, 12/03/2008 - 10:55

Hello Glen,

I think the behaviour of access ports has changed over time to avoid simple vlan hopping.

Now, the behavior should be:

untagged frames and frames tagged with a vlan-id = access vlan are permitted all the other are denied

In old code frames with whatover vlan-id were accepted and eventually forwarded.

New implementation avoids simple vlan hopping but allows double 802.1Q tag vlan hopping that can be mitigated by using a dedicated native vlan for trunk ports never used on access ports.

( double tag vlan hopping uses frames with a double tag 802.1Q with external vlan-id=access-vlan id)

To be able to transmit tagged frames the ports have to be configured as manual trunks.

Being a lab setup the trunk ports can be configured to allow all known vlans.

This should give the desired "plug and play" behaviour

Hope to help

Giuseppe

epeeler Wed, 12/03/2008 - 12:00

Giuseppe,

Thank you for the response. I'm investigating you idea of forcing the switch ports to trunk. However, the other end of this connection is the endpoint and it is not capable of actual trunking. They are simply inserting the vlan tag into the ethernet frames that the end point transmits.

Will the cisco port stay up and in trunking mode with no trunk capable port on the other end?

I know this is really convoluted but here goes. These endpoints also talk regular IP and as such the switch ports are on vlan 193, where normal IP communications occur. The endpoints are tagging some of their outbound frames with their own vlan information. In other words, it's not a vlan that exists on the cisco switch. It's just an identifier that the receiving endpoint will recognize and process independently of IP communications.

If I set the cisco switch port to force trunking, with a native vlan of 193 (to pass the real network traffic unmolested) would the port then allow the bogus vlan tag to stay on the frame when it gets to another endpoint switch port?

Thanks again. I love lab environments.

Correct Answer
Giuseppe Larosa Wed, 12/03/2008 - 12:32

hello Elliott,

>> the endpoints are tagging some of their outbound frames with their own vlan information. In other words, it's not a vlan that exists on the cisco switch. It's just an identifier that the receiving endpoint will recognize and process independently of IP communications

this is not permitted anymore. You understand the disruptive potential of what you have described above in the network of a bank.

You should define all the vlans that you are going to use only at layer2 (no ip services over them)

make all the ports trunk ports

int gx/y

switchport

switchport trunk enc dot1q

switchport trunk native vlan 193

switchport mode trunk

switchport nonegotiate

the default is that all L2 vlans are permitted

vlan 193 has also L3 services but this is not a problem

this should work

the vlans have to be defined at layer2 (so I hope)

Hope to help

Giuseppe

epeeler Wed, 12/03/2008 - 12:36

Thank you Giuseppe. I'll give that a try and report back.

And yes, I absolutely understand the potential for mischief here. Such is life in the lab.

epeeler Mon, 12/08/2008 - 11:27

I just wanted to follow up on this with my results for the sake of completeness.

Giuseppe's advice was spot on. We forced the switch ports into trunk mode and added the vlan that the endpoints were using into the switch's vlan database and this worked. Note that we did try forcing the ports to trunk without adding the vlan itself onto the switch but, even though the trunk said that vlans 1-4096 were allowed on the port, the frames tagged with the endpoint vlan were not forwarded until the switch had that vlan in it's database.

Thanks to everyone who responded and to you especially Giuseppe.

Giuseppe Larosa Mon, 12/08/2008 - 11:36

Hello Elliott,

nice to hear that current implementation of modern switches is more secure then the old one.

The need of existance of the vlan in the vlan database for allowing the frame through a trunk port should come also from the fact the vlan has to be listed in the third field : the port must be in STP forwarding state for the vlan / STP instance associated to it (one to one with PVST, a group of vlans to one STP instance with MST).

Thanks for your kind remarks: I took part in L2 security tests 4 years ago so I have some experience in this suject.

Best Regards

Giuseppe

Actions

This Discussion