Why VLAN Tag is inserted at trunk port in frames that will be carried over TRUNK link?

[ashish7aditya]

I was trying to understand the need of VLAN Tag in frames over the TRUNK link ?

My understanding: Example two switches i.e. switch#1 & switch#2 are connected through TRUNK link.

PC#1 ------Connected through switch#1 via access port(under VLAN#1)

PC#2 ------Connected through switch#1 via another access port(under VLAN#2)

PC#3 ------Connected through switch#2 via access port(VLAN#1)

PC#4 ------Connected through switch#2 via another access port(VLAN#2).

Now, if PC#1 & PC#2 respectively want to ping PC#3 & PC#4 then benefit of preserving VLAN tag over the trunk link(common path) will be that switch#2 will become intelligent & will narrow the broadcast same like switch#1. i.e. moment switch#2 will receive tagged frame from PC#1(VLAN#1 tagged over trunk link), then during ARP(if required) will send the broadcast to all ports which are under VLAN#1 only. Thus, will narrow the broadcast.

Even if there was no concept of tag preservation over the trunk link, then also ping will occur successfully. Only thing is that in this case Broadcast on switch#2 will be bigger than switch#1(as switch#2 will not understand which VLAN the frame belong to & therefore will send to all the ports except the port it received i.e. basic LAN switching concept).

Again saying, switching will be still OK as it is done based on S & D mac.

|||||||||||||||||||||

Please can any expert comment on this understanding. Is this correct?

[Jon Marshall]

I'm not sure what you are asking.

If there was no concept of vlan tags then all your PCs would need to be in the same vlan on both switches.

So when you say switching would be okay it would if all PCs were in the same vlan.

But not if you are using multiple vlans.

If there is no tag with the frame the receiving switch will assume it is the native vlan so it will not flood it to all ports in both vlans.

It will flood it to all ports in the native vlan only which may or may not be the vlan of the PC you are pinging.

Jon

[ashish7aditya]

Hello Marshal,

Firstly many thanks for your support & feedback .. I agree with you but my point was different.

I will try to explain my point once more & accordingly let me know if correct or incorrect.

For a while, ignore the concept of native VLAN over the trunk link. Native VLAN came into picture after the concept of sending tag frames over the trunk link. But if there was no concept of sending the tag frames over the trunk link then there was no meaning of defining or introducing one dedicated native VLAN.

My point was to understand the need of sending tag frames over the common pipe line i.e. TRUNK link. and what will be the challenge if there was no concept of tagging the frames over the trunk link?

We know that Access port doesn't insert any tag into the frames but still put the traffic into access vlans, similarly if there was no concept of inserting the VLAN tag in the frames when going over the trunk link then also all the above pings should be successful (based on the S & D mac addresses present in the frames).

Challenge here will be that when switch#2 receives untagged frames over the trunk link(from PC1 & PC2), it will not understand which VLAN these frames belongs to & therefore will do the ARP for all the ports and finally after receiving the D. MACs & will forward the ping msgs to corresponding destination PCs.

Is this correct?

[Jon Marshall]

The pings would not necessarily be successful.

A port is either an access port in which case you would only be able to ping between the PCs in that vlan or it is a trunk link.

If it is a trunk link it has to tag frames because otherwise it makes no sense ie. the receiving switch has to know which vlan it is meant to be in.

You are saying if there is no tag the switch will broadcast the arp into all vlans which is incorrect.

Jon

[ashish7aditya]

Thanks Daniel & Jon..

but Jon: Why switch#2 will not broadcast the arp to all the ports (under different VLANs) ? Switch#2 doesn't know which VLAN the frame it received(untagged frame over the trunk link) belongs to but that shouldn't stop him in forwarding the frame to correct destination..

At the end I agree that practically it will not do as switches work on the well known concepts of Access & Trunk ports and not on the concept that one I mentioned.

Having said this, I was just thinking of an issue or challenge that drove the developers to include tag in the frames over trunk link. I mean there could have been other way during development of switches i.e. send untagged frames over the trunk link & receiving end switch will forward the broadcast frames to all the ports(common B.C domain) but in this case the drawback would be that while sending any broadcast data from one switch to other, it will be a broadcast towards all the ports unlike limited to corresponding VLANs & thus there was a better option to follow tag frames over the trunk link and limit the broadcast domains.

...

[Jon Marshall · Accepted solution]

The concepts of vlans is to create broadcast domains and segregate traffic.

If, as you propose, a trunk link could send untagged broadcast traffic to all vlans you have just defeated the whole purpose of using vlans.

Jon

[dasiimwe]

Again I agree with Jon you will have to read the 802.1q  rfc to answer the 'why' question but as Jon said "you would just defeat the whole purpose of using vlans" which is to limit the broadcast domain.

edit: Remember that the people who developed these technologies are very smart Individuals with Phd level knowledge, questioning the 'why' is ok if you want to better understand the technology but avoid trying to challenge the 'why' until you fully understand the technology.

[ashish7aditya]

Thanks Jon & Daniel for your support.. I got the concept now..!

Aside Daniel: I completely agree with your view on the point 'Why' that I raised previously. It was just to understand the technology better & surely not to challenge anyone.

"I drew 2 switches on packet tracer and connected them via trunk link then I started thinking that why it will be must to keep tag on a TRUNK link ? Possible thoughts that I came across were -

1) Must to do switching(to let packet to reach exact destination);

2) To narrow the BC domain and make 2nd switch also aware of the VLAN to which an incoming frames belongs to(over the trunk link belong to);

3) Comparison of these though with how access ports work(which doesn't include any tag).

Finally I opened the discussion here (but again to clarify my understanding & not to challenge anyone).

|||||||||||||||||||||||||||||||||

After long discussion I built below understanding:

1) It will be essential to preserve Tag over the Trunk link so that other end device (2nd switch here in ex) can also become intelligent & can distinguish the traffic coming towards it under multiple VLANs. Thus finally can narrow the BC and can perform VLAN aware switching.

2) It is correct that access ports doesn't include any tag but at the same time this switch port is clear that any traffic that it will allow will follow particular VLAN (per port) only other wise it will discard the frames.

3) It will be meaningless to think that if we will send untagged traffic over the trunk link then still it will reach destination because if you are working on VLAN aware switches then firstly it will put all traffic under native VLAN & therefore if destination port is under this native VLAN then it may reach its destination(infact arp BC will occur for all ports under VLAN=Native VLAN)

Secondly if you think of ignore the concept of native VLAN and concept of tagging the frame over trunk link for a while (just for understanding the case if there was no VLAN tagging at all over the trunk link), then switch should definitely know to which VLAN incoming frame belongs to otherwise, it will defeat the purpose of VLANs.

And if you are just thinking from switching perspective i.e. frame has S & D mac therefore it should still reach destination then it this case better work on switches which don't understand VLANs or say has one B.C only & then it may make sense of sending any traffic over trunk link & will reach destination. Alternatively in this case there will be no concept of TRUNK, ACCESS,NATIVE VLANS. All without vlans and all traffic without any tag information i.e. one common flow with S&D mac(&IPs) therefore only one BC domain.

I believe now its OK..?

Best Regards!

[dasiimwe]

you have to remember that vlan 1 is the native vlan by default so all untagged frames are forwarded to the native vlan. So this would only work for vlan 1. If you used vlan 2 and 3 in your example or if you changed the native vlan to vlan 10 the ping would not be successful for untagged traffic.