Thanks Martin. If the switch is configured to only accept traffic from VLAN 20 for instance, I am assuming that traffic between the switch and host is untagged? If yes, how would this be different to untagged traffic?
For the switch to know its VLAN 20 the traffic would arrive at the switch as tagged traffic (in a trunk). ON the switch you could either decide to include VLAN20 in a trunk or you could assign ports for access to VLAN20.
1 Like
To clarify Martin, do you mean to say that on the switch the port does not need to configured as a trunk port?
I’m struggling to help clarify things here. In an attempt to improve that, I have drawn some switches and VLANs to demo what can be done. Now this is NOT what should be done - its a stinking mess of a network, but you can see how this could work.
2 Likes
Let me try my hand at a very simplified world-view (with the caveat that it is simplified - there are variants and tweaks, particularly when it comes to handling untagged frames):
Assume
- A device D (e.g., a router, a switch or really, any device)
- A network connection N (e.g., an ethernet cable to somethng)
- A port P between the device and the network
Terminology: “untagged” is often referred to as VLAN ID 1
Generically:
Assume an access port P, VLAN ID = 20
A frame arrives at P from the device side:
if tag = 20 then
remove tag
transmit to the network side
else
drop the frame
A frame arrives at P from the network side:
if tag = 20 or untagged then
add tag 20 (if not already there)
transmit to the device side with tag 20
else
drop the frame
Assume a trunk port P, VLAN member IDs = {20, 30}
A frame arrives at P from the device side:
if tag = 20 or 30 then
transmit to the network side (unchanged)
else
drop the frame
A frame arrives at P from the network side:
if tag = 20 or 30 or untagged then
transmit to the device side (unchanged)
else
drop the frame
Simply think of trunk ports as filtering (only let member VLAN frames through) and access ports as labeling (strip or add tags (“labels”)) depending on the frame’s traveling direction.
To see how thing work when you assemble a network of devices apply the above ruleset to each port on every device.
A few scenarios:
Two ports on the device (the router):
-
PortA: Configured as an access port for VLAN 20
-
PortT: Configured as a trunk port, members being VLAN ID 10, 20 and 30
-
A set of five VLANS: untagged (“VLAN 1”), 10, 20, 30, 40
-
Two devices (Routers, PCs, laptops, switches, whatever):
- DeviceA connected to PortA
- DeviceT connected to PortT
-
DeviceA transmits an untagged frame [FU]
- [FU] arrives at PortA
- PortA passes it on to the router with a VLAN 20 tag added ([FU-20])
- The router passes [FU-20] to PortT
- PortT recognizes [FU-20] as tagged with a trunk member ID tag
- PortT transmits [FU-20] onto its ethernet with the VLAN 20 tag intact.
and life goes on.
-
DeviceT transmits an untagged frame [FU]
- [FU] arrives at PortT
- PortT passes [FU] on to the router untagged
- The router passes [FU] to PortA
- PortA recognizes [FU] as not being tagged with its member ID tag (20)
- PortA drops the frame [FU]. No device connected through PortA will see [FU]
and life goes on.
-
DeviceT transmits a tagged frame tagged with VLAN 20 [FT-20]
- [FT-20] arrives at PortT
- PortT passes [FT-20] on to the router unchanged
- The router passes [FT-20] to PortA
- PortA recognizes [FT-20] as being tagged with its member ID tag (20)
- PortA transmits the frame [FT] with the tag (20) removed, i.e. untagged
and life goes on.
-
DeviceT transmits a tagged frame tagged with VLAN 30 [FT-30]
- [FT-30] arrives at PortT
- PortT passes [FT-30] on to the router unchanged
- The router passes [FT-30] to PortA
- PortA recognizes [FT-30] as not being tagged with its member ID tag (20)
- PortA drops the frame [FT-30]. No device connected through PortA will see [FT-30]
and life goes on.
-
*DeviceT transmits a tagged frame tagged with VLAN 40 [FT-40]
- [FT-40] arrives at PortT
- PortT recognizes [FT-40] as not being tagged with a trunk member ID tag
- PortT drops the frame [FT-40]. The router will not see [FT-40]
and life goes on.
I know. TL;DR
2 Likes
Thanks. Can you further elaborate on what you mean by device side and network side?
Why does portA transmit the frame [FT] with the tag (20) removed?
Because that is how the IEEE 802.1q standard (IEEE Standard for Local and metropolitan area networks—Bridges and Bridged Networks) is defined.
The rationale is that IEEE 802.1q (VLAN) frames are different from IEEE802.3 (the ethernet standard) frames.
Consider equipment with 802.3 support only - e.g., your basic networked printer, a computer, a PC… It would not know how to handle a tagged frame, and would drop it. Thus access ports are the means by which you connect such equipment to the device (router). 802.3 frames are tagged when passed on to a trunk, and detagged when passed on to the 802.3 equipment.
PortA is an access port, and thus cannot expect to that equipment connected to it has any knowledge of 802.1q frames.
2 Likes
A port is part of a device (a router, switch, computer, whatever).
It is intended to be connected to a physical network medium (a cable).
It transmits bits between the cable (network side) and the device (device side).
1 Like
Thanks Zegor. That’s very helpful. To clarify, does that mean that devices connected to access ports should be limited to those that do not support tags? If yes, how does one establish as to whether a device supports tags or not?
My understanding is that an access port can assign a label that is representation of a tag. Is that correct?
Does that mean that the network side is always the medium over which bits are transmitted?
No. Devices that understand 802.1q are likely (pretty much guaranteed) to understand 802.3 as well.
On the device side a frame arriving at the access port from the network side will be treated for purposes of level 2 routing as if t were tagged with the associated VLAN.
[It is more complicated than that, but for the purposes of understanding how your architecture works this will suffice.]
Z
1 Like
In that case, why have access ports at all? Would it make sense to only have trunks that support 802.3 devices?
No, it would not make sense. And more to the point - that is not how the standards work. Having said that - vendors vary in how they handle trunk ports, and some switches combine some of the functionality of access ports with that of trunk ports. But access play a different role than trunk ports (cfr. the description earlier - trunk ports are filters, access ports are labeling).
1 Like