cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2652
Views
14
Helpful
12
Replies

Example of untagged traffic?

ccnaluna93
Level 1
Level 1

I know that the native vlan is used for untagged traffic and from what I've googled an example of untagged traffic could be STP or VTP management traffic this makes sense to me but the other kind of traffic could be from a legacy device that does not have VLAN tag capability, but how is that possible? I mean if you have such a device then I guess you will connect it to a switch port and as we know every switch port has a vlan tag, if you don't configure anything then vlan 1 will be used... could you please help me to clarify this? how can we have such untagged traffic?

2 Accepted Solutions

Accepted Solutions

Thanks for the additional information. In reference to this statement " as we know every switch port has a vlan tag" perhaps we really are facing an issue with semantics more than with function. When you say vlan tag I assume that we are talking about the extra data that is inserted into an Ethernet frame to identify vlan membership. And not every switch port has a vlan tag. If you change the statement to say that every switch port has a vlan ID then I would be in complete agreement with your statement. And the vlan ID is how the switch knows how to forward layer 2 traffic keeping the frame in the correct vlan.

And yes the terminology if not used the same way by different vendors (HP vs Cisco, etc).

You ask an interesting follow up question "but when will we have frames that don't come from a vlan?" I can think of a couple of possible answers:

- if an Ethernet frame came from a router interface (physical interface - not subinterface) then we might say that it did not come from a vlan.

- similarly if an Ethernet frame came from a PC then we might say that it did not come from a vlan.

- some people might say that if an Ethernet frame came from an unmanaged switch it did not come from a vlan. I would not agree with that. From my perspective any switch (managed or unmanaged) implements a vlan. They might not configure the vlan, but a vlan is implemented in the sense that they have created a broadcast domain that controls which ports can communicate with which other ports.

HTH

Rick

View solution in original post

There is no need for apologies. We tend to use terms a bit loosely. And that can generate confusion about how something works. Sometimes that is what a discussion is really about. And sometimes the answer to the question is to be more careful about how we have used terms. As in the difference between a vlan ID and a vlan tag.

And it may help if we think about this in terms of the historical context. Back when this was being developed there were multiple trunking protocols (Cisco had ISL, 3Com had VLT, IEEE had 802.1Q etc). So there was a very real possibility that a trunk port (using 802.1Q) might connect to a device that did not understand 802.1Q vlan tags. So implementing the native vlan was a way to assure that some essential functions (like spanning tree) could still work. In today's environment it would be difficult to find a device that did not understand 802.1Q tags and so the real need for native vlan is not significant - but it still exists.

 

HTH

Rick

View solution in original post

12 Replies 12

Richard Burts
Hall of Fame
Hall of Fame

The original post says "the other kind of traffic could be from a legacy device that does not have VLAN tag capability," Yes it might be a legacy device, but it could also be just a normal (current generation) PC which by default sends Ethernet frames with no vlan tag.

The original post also says "as we know every switch port has a vlan tag," This is a misunderstanding. It is not true that every switch port has a vlan tag. Any switch port configured as an access port will not have a vlan tag. vlan tags are used only on switch ports that are configured as trunk ports.

 

HTH

Rick

Well, you are right, but every frame from a PC that enters a switchport is put in a VLAN, just like this image:

 

trunk.png

 

Just like you said, the frames from a PC are untagged and access ports don't tag them, but they are in a specific vlan then when they go to a trunk port they are tagged according to the vlan they belong, that was what I meant before, every switch port is assigned to a vlan, so they will have their proper tag, but when will we have frames that don't come from a vlan?

 

Thanks for the additional information. In reference to this statement " as we know every switch port has a vlan tag" perhaps we really are facing an issue with semantics more than with function. When you say vlan tag I assume that we are talking about the extra data that is inserted into an Ethernet frame to identify vlan membership. And not every switch port has a vlan tag. If you change the statement to say that every switch port has a vlan ID then I would be in complete agreement with your statement. And the vlan ID is how the switch knows how to forward layer 2 traffic keeping the frame in the correct vlan.

And yes the terminology if not used the same way by different vendors (HP vs Cisco, etc).

You ask an interesting follow up question "but when will we have frames that don't come from a vlan?" I can think of a couple of possible answers:

- if an Ethernet frame came from a router interface (physical interface - not subinterface) then we might say that it did not come from a vlan.

- similarly if an Ethernet frame came from a PC then we might say that it did not come from a vlan.

- some people might say that if an Ethernet frame came from an unmanaged switch it did not come from a vlan. I would not agree with that. From my perspective any switch (managed or unmanaged) implements a vlan. They might not configure the vlan, but a vlan is implemented in the sense that they have created a broadcast domain that controls which ports can communicate with which other ports.

HTH

Rick

Apologies for my semantics problem those are interesting ideas the reason for my question is because I wanted to know what traffic would be put on the native vlan the pc traffic would not be put on that native vlan because it comes from a port that has a vlan id but the interface router traffic would be put into a native vlan like you said

There is no need for apologies. We tend to use terms a bit loosely. And that can generate confusion about how something works. Sometimes that is what a discussion is really about. And sometimes the answer to the question is to be more careful about how we have used terms. As in the difference between a vlan ID and a vlan tag.

And it may help if we think about this in terms of the historical context. Back when this was being developed there were multiple trunking protocols (Cisco had ISL, 3Com had VLT, IEEE had 802.1Q etc). So there was a very real possibility that a trunk port (using 802.1Q) might connect to a device that did not understand 802.1Q vlan tags. So implementing the native vlan was a way to assure that some essential functions (like spanning tree) could still work. In today's environment it would be difficult to find a device that did not understand 802.1Q tags and so the real need for native vlan is not significant - but it still exists.

 

HTH

Rick

 

Doesn't really matter what device the frames come from if the switchport is L2 then it is coming from a vlan eg. a PC that is sending untagged traffic is still in a vlan. 

 

If the port is configured as a L3 port then you could argue it is not in a vlan although I believe the underlying implementation still uses vlans but could be wrong on that. 

 

Jon

Joseph W. Doherty
Hall of Fame
Hall of Fame

Overlapping, somewhat, with what Rick already described.

Actual VLAN tagging deals with addition data added to L2 frames.  I.e. originally (I believe?), Ethernet did not provide for such tagging.  Untagged frames are still very much current, and generally the default for how frames are generated.

VLAN capable switches (not all switches are VLAN capable) do assign each access/edge port to a VLAN.  How a switch manages to identify/track frames, within the switch, from different VLANs, is proprietary.

VLAN tagging is only needed when we desire to send frames, from different VLANs, across the same media.  The "tag" allows the sender and receiver to identify which VLAN a frame belongs to.

On Cisco equipment, ports configured to send/receive tagged frames are "trunk" ports.  Cisco equipment (excluding very old devices) also generally support a mini trunk port, defined as an access port which supports two VLANs.  These latter access ports are generally used to have a data and voice VLAN on the same port.  Also for these ports, generally, the data VLANs is untagged and the voice VLAN is tagged.  (Again, tagging refers to the tagged frames being sent or received, externally, on the port.)

BTW, other vendors can use different terminology for the same feature.  Also, some other vendors don't support tagged and untagged frames on the same port, excluding their support of dual VLAN edge ports.

Thanks for such a good explanation, the last part you said helps me understand HP switches because they use the term "tagged" and "untagged" for some configuration commands, I also replied to Richard about my point, it would be nice if you could check it too

Again, for VLAN capable switches, every port has some VLAN assignment.  (Although as Jon mentions, L3 switches that also support "routed" ports aren't, logically, within a VLAN, although I understand, under-the-covers, a L3 VLAN switch does actually assign such ports to a VLAN, for internal frame tracking.  However, further understand, these under-the-covers VLAN frames cannot be sent directly (like other VLAN frames) to a Cisco trunk port.

BTW, both Rick and/or Jon appear to consider frames from untagged hosts, or non VLAN switches, still in a "VLAN".  Well yes and no.  Remember a VLAN is a "Virtual Local Area Network", i.e. it emulates what hubs and switches provided before there were VLANs. i.e. LANs.  What VLANs allow is multiple instances of what used to be only a single instance (shared Ethernet media) on a hub or switch.  Or, as Rick further describes, an instance of a broadcast domain.

Rick also mentions, VLAN ID vs. VLAN tag, which might, indeed, be a point of confusion for you.  The VLAN tag is an identifier added to Ethernet frames for VLAN frame identification between devices.  A VLAN ID is what, again on a VLAN capable switches, assigns every frame to within the switch.  Again, how the switch manages frames (internally) vis-a-vis VLANs, is proprietary.

As Rick also describes, how switches tag VLANs to frames, externally, might be different.  ISL, I recall, both predates .Q and was proprietary.  In fact, I recall, .Q was defined to allow everyone (else) to use a standard for VLAN tagging (which, also BTW, Cisco was a tad late in adopting as they had ISL).

Just to muddy the waters a bit, if you wanted to "share" (i.e. same broadcast domain) frames between two switches, you might define a port on each switch with the same VLAN ID, e.g. 2, and connect the ports.  Or, you might define both switch ports, which you will interconnect, as (Cisco) trunk ports and allows VLAN 2 to use those ports.  For the latter, assuming VLAN 2 is not defined as the native VLAN, each switch will add a VLAN tag, to identify frames as belonging to VLAN 2.

But, you might also define one switch's port as VLAN 2, and the other switch's port as VLAN 3, and interconnect them.  This will also work, effectively making VLANs 2 and 3 one broadcast domain.  It works because the frames, on non-trunk ports (excluding "voice" VLAN assignments) will send receive frames untagged; same as the VLAN 2 <> VLAN 2 case.  However, on Cisco switches, with CDP active on the port, it will flag a VLAN mismatch for something like VLAN 2 <> VLAN 3.

This has been an interesting discussion. I am glad that our explanations have been helpful. Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.

HTH

Rick

Thank you very much for the information! This is a very nice place to talk about these topics.

You are welcome. I agree that this is a nice place to talk about networking topics and to learn new things. When I was very new to networking I discovered a similar community where I learned a lot. Now that I am experienced in networking I enjoy sharing what I have learned. I hope that as you become more experienced in networking that you also will want to share what you have learned (in this community or in some other place).

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco