VLAN tagging Q

Hola,

i thought that i had a grasp on Vlanning.... but today has been a humbling day at the j.o.b.

Working with a frustrating "SG 200-50P",
i thought it would be quite simple to create a new VLAN (Using the dumb web-interface)... and do some 'ping testing' between hosts.

Well,
creating a new vlan was simple enough.
But looking cisco's support forums.... i see lots of Tagging references ---> 'U' 'P' & 'T'

For example:
"port 1 is the link to your router - 1UP, 2U, 3U
port 2 is the link to host a - 1U, 2UP"
(blah blah)

After doing some digging,
it looks like they are referring to --> 'Untagged', 'PVID', & 'Tagged'

My question:
What exactly are these tags, and what do they do?

Find more posts tagged with

Comments

TWX

That doesn't make a whole lot of sense as-described, one cannot have three untagged VLANs on a port.

volfkhat

Right!

Apparently the switch has functionality where you can configure "General" mode (on the port), which allows the Port access to multiple vlans??

https://supportforums.cisco.com/discussion/11797251/vlan-setup-sg-200-26p#4166596

I'm really, at a lost.
But that's beyond the scope of my immediate issue.

Namely, could someone explain:

What is 'Untagged', 'PVID', & 'Tagged' all about?

james43026

An untagged frame, is exactly that, it is a frame that hasn't been tagged with VLAN information, essentially this is any access port, a tagged frame is any frame that has a VLAN ID injected into the header via 802.1Q, or has a new header added to the frame VIA ISL, this happens on trunk port, and as such a tagged port is a trunk, HP calls their trunks tagged ports, and they call their access ports untagged ports. A PVID is literally a switches way of tracking what VLAN an access port / untagged port belongs to, without applying a VLAN tag.

volfkhat

james43026 wrote: »

An untagged frame, is exactly that, it is a frame that hasn't been tagged with VLAN information, essentially this is any access port, a tagged frame is any frame that has a VLAN ID injected into the header via 802.1Q...

hmmm....
but aren't all ports on a switch by 'default' in Vlan 1?

So... wouldn't that mean that all ports are 'tagged' as vlan1?
Thus, all ports on a switch are defaultly in a "trunk" mode.

Surely This is not the case...

volfkhat

Allow me to refocus:

Suppose that I have test lab consisting of:
1 switch, and 3 PCs.

PC1 is plugged into Port 1.
PC2 is plugged into Port 2.
PC3 is plugged into Port 3.

I set Port 1 = Vlan 1.
I set Port 2 = Vlan 2.
I set Port 3 = Vlan 3.

So...
how does the tagging play out?
What goes where?

The way i was taught... all three ports would be in "access" mode (no matter which VLAN i decide to assign to the port).

But i never learned how Tagging comes into play $:\$

If i had to take a wild guess....
i'd say that the 'tagging' has to do with the ports that are in trunk mode....
but i am unsure how.

OfWolfAndMan

volfkhat wrote: »

If i had to take a wild guess....
i'd say that the 'tagging' has to do with the ports that are in trunk mode....
but i am unsure how.

Aside from providing multiple virtual segments on one physical device, a VLAN, if you recall, was also sometimes used for subnet isolation. The above statement is accurate. An access port carries one VLAN (Unless you have an auxiliary VLAN piggybacking, then two, but let's not get into that), and a trunk carries many. To ensure traffic doesn't "leak" between those VLANs, tagging is relevant when it traverses the trunk to keep the traffic organized, using tags, to allow in some situations, ONLY that specific subnet to receive traffic.

From a vendor-neutral perspective, "Untagged" means an access port, and "tagged" means trunk port. The port is considered "untagged" because when the information ingresses the port, it originally has no VLAN information in the header. The PVID determines its VLAN association, and when it traverses over the trunk, it knows which ports it can forward that frame to because of the tag that was retained.

Do not confuse "Untagged" port with Native VLAN. One word, two different meanings, depending on the context of the question.

pevangel

Think of VLANs as tags. Frames that do not have VLAN information are untagged. Frames that have VLAN information are tagged.

Access ports will accept untagged frames. Trunk ports will accept tagged frames. Trunk ports will also accept untagged frames if a native VLAN is configured.

TWX

"Tagging" or trunking requires the VLAN-aware device to modify the Ethernet frame header to insert the VLAN tag, and to then recompute the frame check sequence. Untagged frames do not intrinsically belong to any VLAN, the concept of the VLAN tag and VLANs was not initially part of Ethernet. As others have said, if a switch interprets an incoming frame as belonging to a particular VLAN it's because it either knows that the access-port that the frame comes in on is assigned to a given VLAN (which the PC or other host plugged into that port may not be aware of) or because a trunk port-port that is meant to handle VLANs is configured to know that when it receives Ethernet frames that lack tags, to consider them part of the VLAN that's been programmed that way, or the "native VLAN."

When VLANs were conceived of Hubs were still widely in use. It was not inconceivable that a hub with conventional users on it could span the link between two VLAN-capable devices. Both that hub and dumb switches would be capable of forwarding both tagged traffic and untagged traffic equally, so the idea was that the VLAN intended for users could be set as the native VLAN on such a link, and the switches would know which traffic was from those users and which other traffic was for other VLANs.

In practice, it is a terrible idea to put a hub between two trunked switches to use the native VLAN for the PCs, hubs would send all traffic to all ports, including VLAN-tagged traffic, so someone with software like Wireshark could record the entire trunk's traffic, and even with dumb switches there are still plenty of options for easy exploitation, but having a native VLAN that doesn't use tagged frames allows for non-VLAN-aware devices to communicate through what otherwise would be trunk interfaces.

volfkhat

Wolf, Pev, TWX,
thank you all for the insight. It makes logical sense.

After much reflection....
i think my confusion stems from the switch's presentation/web-interface.

It's goofy... but i will not 'question' what i 'thought' i already know :]

crap.jpg

TWX

Heh. crap.jpg sums it up rather nicely.

--chris--

volfkhat wrote: »

Wolf, Pev, TWX,
thank you all for the insight. It makes logical sense.

After much reflection....
i think my confusion stems from the switch's presentation/web-interface.

It's goofy... but i will not 'question' what i 'thought' i already know :]

I sliced up a flat network last spring that was all SG200/SG300's. There is a nasty bug in the 300's firmware (forget which version) that strips all vlan tags when a frame hits a trunk. Makes segmentation impossible.

The interfaces on those are total **** and you can not work via cmd line on the 200's. The 300's offer a cmd line, but its a neutered version of IOS with many useful commands missing...like sh vlan br...and sh mac-add..

You only want access or trunks (I believe general ports act like access, but I don't see why the exists...so I avoided them). The hardest part is keeping track of the drop down VLAN selection menu up top lol...be careful when moving between vlans.

volfkhat

Okie dokie!

After accepting that this intetface just SUCKS... I have actually made great progress!

So now, I have a new Question:

Can a Cisco SG-200 pass multiple VLANS to a Dell SonicWall (TZ-215) to handle the intervlan routing?

I would assume the answer is YES; that's why 802.1Q exists, right?

Unfortunately, i am having very little LUCK (can't even ping); but i just wanted to confirm that it 'should' work.
(at this point, i suspect their is more configuration needed on the Sonicalwall port)

Thanks again :]

TWX

In theory everything that meets IEEE 802.1Q should interoperate. The only headaches I've personally experienced are when something expects a specific native VLAN and the other end isn't set up that way.

OfWolfAndMan

While something may comply with 802.1q standards from a hardware perspective, it doesn't mean the software has the capabilities built in. I.e. there are many home routers that do not have the interVLAN/tagging capability unless you install custom firmware. Google will be your friend for that one.