I'm reading Wendell Odom's books and I have a question regarding VLANs and trunking. As far as I understood trunking is needed when you have network which is splitted between several switches. When a host sends a broadcast it has to be delivered to all hosts from that VLAN on all switches. Switches in its turn need to know VLAN ID when packet comes from another switch. Otherwise it won't know where to deliver the broadcast.
So in short, my understanding is that trunking is needed only for delivery of broadcasts (or packets to yet unknown hosts, when packet is also flooded to all VLAN and trunk ports) between switches and only in cases when network is splitted between them.
But I also read that trunks are needed between switches and default gateways for networks which that switch services. But I don't see the reason for that. Say, you have switch1 vlanA, switch2 vlanB. There are no broadcasts between the switches. And if host from vlanA needs to deliver unicast packet to host from vlanB, then packet is routed using general rules. It is delivered to default gateway and then to the corresponding switch. Who needs to know VLAN IDs here and for what reason?
Just need to stick to one point:
Once we enabled VLAN - switch maintains the separate CAM table for it. So all destination MAC lookups done through it.
We already discussed broadcast and unknown unicats. But for known unicast switch will look into VLAN specific entries in cam table. That it populated to HW ASIC and adds speed to packets forwarding. If you don't use tags you wont find the correct entry all entries are linked to particular VLAN. Keeping the Global CAM table not linking it to VLAN is not efficient. Imagine packet coming from trunk to switch - if it is tagged it is doing simple lookup through rather short CAM table for that specific VLAN. If it had no tag we should have used the CAM covering all VLANs - and lookup would be much longer which is not efficient.
So here it is not the questions - not to use tag if I don't want. Yes in theory packet can be sent only by destination MAC which is usually unique (BUT NOT ALWAYS as you can configure your own MAC on some interfaces ), but once you configured VLAN - you need to stick to consistency across all switches. That is how it is implemented in SW and HW and I guess it is common for all vendors. That is why tagging is important (tagging is only specific for links which pass many VLANs).
Your understanding is right. In this particular scenario, we don't need tagging. Hence, using access port between switches and router should make this work.
Now while packet is traversing down across trunks each switch looks up for destination MAC and if switch doesn't find it, sends it to the next trunk.
The switch will actually flood the packet to all ports in the vlan in which the packet belongs to. If that vlan is allowed in a trunk port, then the packet will be forwarded to that trunk port as well.
Hence by design, all the traffic that has to be sent through a trunk port [except for the native vlan] will be tagged. The switches are not smart enough to identify situation and use the tagging accordingly. Hence, it is upto us to design the prots. As per the switch, if it's a trunk port it uses tagging [except for the native vlan] and if it's a access port it doesn't use tagging.
I understand your concern this way - if MAC address is unique then why we need VLAN for unicast L2 packet transfer if that can be just done using destination MAC lookup.
In very simple situation it can be done, YES. But networking is not that simple now. Agree that concept of VLAN started with broadcast domain. And in the beginning each unicast is unknown unicast for switch which is sent out of all ports to get it to the destination - so this is the first use of VLAN - limit the scope for Unknown unicast.
Once it is known and the switch learnt destination MAC on its CAM it can forward packet by dest MAC and no scope limit needed as we have single destination port. But imagine switch is reloaded or CAM table age timer expired and all MAC deleted - now your unicast is unknown again - if you did not use the VLAN by that time you will flood all the ports with it until your learn the destination MAC in CAM. So it is not like - we need VLAN only for broadcast - we need it for unicast to scope the limit of outgoing ports when dest MAC is unknown. And once this VLAN is configured we can't say - tag only these unicast packets and don't tag other ones - we tag all - this is the concept.
Other thing to support VLANs for unicast - imagine that packet came to its final egress port. To that port you have IP Phone and PC connected. Those by design in different broadcast domain - so in different VLANs. PC VLAN is untagged, and voice VLAN is tagged as IP Phone can understand this encapsulation. If you packet was voice and you lost your VLAN tag already - you will send it to PC untagged even if you have correct destination MAC of IP Phone and it will be dropped on PC due to incorrect MAC.
Third situation is when egress port is connected to server hostying multiple Virtual machines. Those may share same physical MAC but server may support dot1q tagging and put those in different VLAN. SO again if you lost your VLAN tag through the switches you wont be able to reach correct server.
Thus questions of VLAN is not only about how to go from one switch to another - it is concept of packet L2 forwarding from one side to the other. Packet originated in one VLAN should always stay there if it is L2 and egress from the last switch in correct VLAN (tagged or untagged based on the device connected).
Vlan concept is further going to L3 routing as explained above in my and Alains posts.
Hope this helps.