Noob question on access port tagging ingress/egress

[pdub206]

When you have a port set up as an access port connected to another switch using an access port, which of the behaviors below is correct?

• Upon ingress to the switch, the port tags the frame based on the vlan assignment.  Upon egress, the port tags the frame based on the vlan assignment (both ways).
• Upon ingress to the switch, the ports tags the frame based on the vlan assignment.  Upon egress, the port does not tag the frame and strips the vlan assignment off (one way tagging).

I have a coworker who told me the first is true, but my studies have indicated the second is true.  Am I wrong or is he?

[Seb Rupik · Accepted solution]

The clue to whether frames leave without a tag is in the lack of encapsulation 802.1x statements on an access port.

The second statement is true.

[jbowman1985]

Seb is correct.  The second statement is the bahvior when an interface is configured as an access port.  

When the switch sends frames out (egress) towards a client, there is no VLAN tag.  When the switch sends the frame from the interface (ingress) to another interface, the switch will apply the VLAN tag of whatever VLAN that interface is configured for.

[Toscana]

Hmm, both answers are wrong. If there is an uplink between two switches and both uplink ports are configured as access ports, there is no tagging.

[Joseph W. Doherty]

I agree both OP choices are incorrect, as written, but you are too, as there can be on-wire tagging between access ports.

Upon ingress on an access port, frames are associated with a VLAN (on a VLAN capable switch) but exactly how that's accomplished is proprietary.  Tagging frames is only known to be done when frames are transmitted.  This to convey information a basic frame is not defined to carry such as a VLAN ID and/or CoS.

.1Q tagging might be on an access port for CoS only.  (VLAN ID zero.)

Later Cisco "access" ports might also be configured for a voice VLAN, their, on wire, voice frames would need tags.

[Toscana]

“Tagging frames are only performed when frames are transmitted.”

What does this mean? When we talk about what happens inside a switch (not a tagging client such as a virtualization host), I always thought that vlan tagging could only take place when a frame has to egress a port that was configured as a trunk (i.e., an uplink port). There should be no reason to vlan tag a frame coming from a client and entering an access port.

You say this is proprietary?

But it's a good point to point out that tagging doesn't just happen because of VLANs. However, in the case of CoS, the tagging should be done by the client (e.g. the phone). Right?

But again that CoS thing shakes my belief that frames that float through a switch are always untagged and only receive a tag when they exit through a trunk.

[Joseph W. Doherty]

I'm saying tagging frames is defined when sending frames between devices where you want to identify what VLAN (and/or CoS) is to be make known about a frame, as neither is part of a standard frame.  Once the receiving device reads a tag, how it records that information, internally, is up to the device, and such detailed information is usually proprietary, although the device designer could publish such information, there's not a standard for how it's done.

"There should be no reason to vlan tag a frame coming from a client and entering an access port."

How about?

Access port <> VoIP Phone <> PC

or

Access port <> VM server

"However, in the case of CoS, the tagging should be done by the client (e.g. the phone). Right?"

Often right for VoIP phones, but not always, likewise any host might do so too (consider software VoIP phone on PC).

"But again that CoS thing shakes my belief that frames that float through a switch are always untagged and only receive a tag when they exit through a trunk."

I didn't say, internally, frames are untagged, just there are other ways to track internal frames VLAN relationship.  BTW, internally, a frame's information also doesn't need to be maintained in the on-the-wire frame format.

[Toscana]

You emphasize the basic function of tagging (transport of additional VLAN information). But the question here was the one that leads to confusion everywhere: at which point in the switch is tagging done and what does an access port do (and how does all this relate to the troublesome native VLANs)?

In my simple world, it is as follows:

Normal clients (PC, printers) connected to access ports that are grouped in VLANs know nothing about tags, and frames on the way from a PC to a printer are not tagged by the switch. If the printer is connected to a different switch and the frame has to go over an uplink trunk on its way there, a tag is added at the uplink interface and removed at the other end of the trunk. Again, the destination access port with the printer and the printer itself are unaware of all of this. You don't need tags, trunks, native VLANs at all on a switch, even if the ports are grouped in VLANs.

You mention IP phones, but they are not connected to access ports, but to voice or trunk ports (these do not tag either, instead the IP phone itself tags). The PC traffic that the IP phone delivers to the switch is untagged and is also not tagged by the “access part” of this combo port – because access ports do not tag and do not untag.

VM hosts do not attach to access ports if they serve multiple VLANs.

There is often discussion about what an access port does with (incorrectly) incoming tags. Some say the tags are discarded, others say the VLAN in the tag is evaluated and the tag removed, and still others say the frame is forwarded with the tag. Whatever the case, according to the doctrine, this situation should be a misconfiguration because the devices that tag themselves (VM hosts, IP Phones) should not be connected to naked access ports.

In summary:
- Access ports should never see tags
- Switches forward tags on client trunk ports, but they never tag on these (do they untag on ingress after reading the destination VLAN?)
- Switches only tag in exactly one situation: when frames enter or leave an uplink trunk to another switch or router.

Too simplistic?

[Joseph W. Doherty]

". . . at which point in the switch is tagging done . . "

Simply, when the frame is "written" for the wire.  Internally, how frame to VLANs relationship is supported, is device dependent.  (BTW, when I have written proprietary, I'm using it more in the sense only the switch's designer knows for sure, and they may want to keep how they support VLANs secret.  However, the actual techniques being used might not be protected by patents, and other manufacturer switches might employ exactly the same techniques.)

". . . what does an access port do (and how does all this relate to the troublesome native VLANs)?"

It sends and receives frames.  Basically, defining a Cisco port as "access" imposes a bunch of rules for its operation in sending and receiving frames.  Cisco native VLANs do not apply to Cisco access ports.  (We could also have a bit of a side discussion why Cisco even has/allows for a "native" VLAN on a trunk port.  Other switch vendors often do not support this "feature".  We could also have a side discussion on "VLAN 1", for Cisco switches.)

". . .  frames on the way from a PC to a printer are not tagged by the switch."

Not necessarily - again .1Q tags might be used just for CoS purposes.  Although PCs and network connected printers wouldn't normally use .1Q tags for CoS purposes, their NICs might be capable of doing so.

"You don't need tags, trunks, "native" VLANs at all on a switch, even if the ports are grouped in VLANs."

Agreed, although not supporting any form of tagging negates much of the advantage of VLANs, i.e. sharing VLANs, between switches, without needing a dedicated port for each VLAN.

"You mention IP phones, but they are not connected to access ports, but to voice or trunk ports (these do not tag either, instead the IP phone itself tags)."

Hmm, so what do you call Cisco ports configured as (especially f0/3)?:

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa0/4, Fa0/5, Fa0/6, Fa0/7
                                                Fa0/8, Fa0/9, Fa0/10, Fa0/11
                                                Fa0/12, Fa0/13, Fa0/14, Fa0/15
                                                Fa0/16, Fa0/17, Fa0/18, Fa0/19
                                                Fa0/20, Fa0/21, Fa0/22, Fa0/23
                                                Fa0/24, Gig0/1, Gig0/2
10   Data                             active    Fa0/1, Fa0/3
20   Voice                            active    Fa0/2, Fa0/3

interface FastEthernet0/1
 description Data only
 switchport access vlan 10
!
interface FastEthernet0/2
 description Voice only
 switchport access vlan 20
!
interface FastEthernet0/3
 description Data/Voice
 switchport access vlan 10
 switchport voice vlan 20

Further, my understanding is, for f0/3, the Cisco port does send voice VLAN frames with tags.

Also BTW, before Cisco switches started to support access ports with a voice VLAN option (oh, BTW, I'm retired now, but had close to 4 decades working in IT, so what is "history" for many is/was "state of the art" back then), we used to configure ports like:

interface FastEthernet0/4
 description Data/Voice
 switchport trunk native vlan 10
 switchport trunk allowed vlan 10,20
 switchport mode trunk

Basically, the newer voice option better "defines" and configures (there are some other options that get changed, some of which you can manually reconfigure in f0/4 above [e.g. switchport nonegotiate]) the port for the data/voice mix.

"VM hosts do not attach to access ports if they serve multiple VLANs."

Yup, my bad.  I often think beyond Cisco terminology.  What I had in mind wan an "edge" port vs. an infrastructure port.  We often are stuck with terminology that doesn't apply as usage has evolved.

For example, when Cisco pioneered VLANs, "access" ports were really for edge devices, while "trunk" ports were just for inter switch links (remember what Cisco's original trunk encapsulation protocol is called?  A. ISL).  Having a need for multiple VLANs to/from a edge port may not have been envisioned, like my VM server example, or VoIP phones with a downstream PC.  Cisco's VTP, also, by default, uses just "trunk" interfaces.  Again, a protocol designed for network infrastructure maintenance.  Cisco even supports different global configurations for "portfast" based on whether port is defined a trunk or not.  I.e., by default, Cisco makes assumptions about usage of trunk ports vs. non-trunk ports.  (There are also STP assumptions based on whether port is half duplex or full duplex.)

"There is often discussion about what an access port does with (incorrectly) incoming tags. Some say the tags are discarded, others say the VLAN in the tag is evaluated and the tag removed, and still others say the frame is forwarded with the tag."

Keep in mind, a switch's port is physically the same port regardless if defined just access, access/voice, trunk, no switchport (routed), again, just rules of operation change, and some of the corner cases might vary across switch platforms and/or IOS releases.  (Again, think of switches before/after the voice option was provided as a feature.)

Some access ports, may accept a .1Q tagged frame, if the VLAN ID matches what the assigned VLAN is (BTW, this is, I believe, standard behavior for trunk ports and their native VLAN).  Other unexpected VLAN IDs, I would expect to be dropped.

---

@Toscana wrote:

In summary:
- Access ports should never see tags
- Switches forward tags on client trunk ports, but they never tag on these (do they untag on ingress after reading the destination VLAN?)
- Switches only tag in exactly one situation: when frames enter or leave an uplink trunk to another switch or router.

Too simplistic?

---

Too simplistic, no that's okay, but incorrect, in some ways, yes.

"Access ports should never see tags"

Not if also defined with the voice vlan option, or tags just for CoS purpose or, possibly, if tag matches port's VLAN assignment.

"Switches forward tags on client trunk ports, but they never tag on these (do they untag on ingress after reading the destination VLAN?)"

Unclear exact meaning for "forward tags".  As to do they "untag on ingress", again, depends on how switch wants to maintain, internally, frame:VLAN relationship.  Consider ISL and .1Q frame structures are totally different, yet, there was a time when switches supported both trunk encapsulations.  So, which was used internally?  Were both used internally?  Were neither used internally?  Again, not something switch designer reveals.  We only "known" what an ISL or .1Q frame will look like on the wire.

"Switches only tag in exactly one situation: when frames enter or leave an uplink trunk to another switch or router."

So using a trunk to a VM server or data/voice access port never happens?

[Toscana]

"Not if also defined with the voice vlan option..."

I wanted to clarify my understanding of the access port by splitting the special “voice interface” into two different ports: the tagging port and the access port. And the access part of this port, which processes the PC data, should not tag.

"Unclear exact meaning for 'forward tags'"

I meant “switches egress tagged frames to client”. But yes, I think my statement (“they never tag”) is probably not correct, the trunk port will probably set the tag at egress (in the direction of a client such as a VM host), unless the tag is already present when the frame arrives at the switch interface for egress. And I understand your point: It is probably also not clear whether, conversely, when a tagged frame is received from a VM host, the switch port removes the tag.

"So using a trunk to a VM server or data/voice access port never happens?"

My statement referred to the question of who is tagging. And with ingress at a client trunk port, it should not be the switch that is tagging, but the host or the IP phone. But egressing from switch to host/phone, and in this respect my statement is wrong, it is the switch that has to tag.

Thanks for the conversation, Joseph, it was very enlightening for me!

[Joseph W. Doherty]

---

@Toscana wrote:

"Not if also defined with the voice vlan option..."

I wanted to clarify my understanding of the access port by splitting the special “voice interface” into two different ports: the tagging port and the access port. And the access part of this port, which processes the PC data, should not tag.

---

Actually, an access port with the voice VLAN option, is a "special" trunk port interface.  You can connect it, f0/3, to a switch port, configured like I showed for f0/4.  Again, though, there are a couple of subtle differences.  A trunk port will do DTP, unless configured to not do so, while, I believe, a combo access/voice port will not.  A trunk port will forward VTP, I believe, a combo access/voice port cannot.

So, I advise, don't get too hung up on an "access" port is just an edge port, just the set of rules it operates by.  Consider, you can interconnect switches using access ports, just limited to transporting one VLAN, unless it supports the voice VLAN option, when it can transport another VLAN, and the latter doesn't have to be an actual voice VLAN.  I.e. so an access port can be an infrastructure (e.g. uplink) port while a trunk port can be an edge (e.g. VM server) port.  (Getting beyond one vendor's configuration terminology, makes it easier to understand another vendor's configuration terminology, as often they are the same function.)

---

@Toscana wrote:

"Unclear exact meaning for 'forward tags'"

I meant “switches egress tagged frames to client”. But yes, I think my statement (“they never tag”) is probably not correct, the trunk port will probably set the tag at egress (in the direction of a client such as a VM host), unless the tag is already present when the frame arrives at the switch interface for egress. And I understand your point: It is probably also not clear whether, conversely, when a tagged frame is received from a VM host, the switch port removes the tag.

---

Also consider, when switches supported both ISL and .1Q encapsulation, frames could arrive on a trunk using one encapsulation and leave on another trunk using the other trunk encapsulation.  Gets somewhat confusing if actual wire frame format is retained internally, no?

Also consider, many packets may move between access ports, which aren't tagged on wire, so is an actual form of VLAN tag attached to frame within switch?  More likely, I suspect, it's something like a VLAN specific list of pointers, to frames' data.  (I.e. the actual ingress/egress wired frame structure might be constructed, from L2 data, as needed.)

(As a side note, some Cisco architecture documentation notes how frames, which are variable length, aren't stored in a single memory block, but split between 256 byte memory blocks.  [i.e. "On Cisco UADP ASIC based platforms, one buffer contains up to 256 Bytes of data, and buffers are linked together to represent frames larger than 256 Bytes."]  Again, for internal frame management, it's up to the switch how to manage its operation.  I'm not saying a switch might not use a direct frame structure, internally, including a .1Q tag, but I wouldn't presume it does, either.)

---

@Toscana wrote:

Thanks for the conversation, Joseph, it was very enlightening for me!

---

You're most welcome.  I enjoy questions and discussion just beyond "I need a fix for this problem".