cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
15683
Views
0
Helpful
24
Replies

VLAN Basics

Harmont12345
Level 1
Level 1

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?

--- Nikita Andreev
24 Replies 24

Hi,

ok so this is rather simple, you have vlan A and vlan B on sw1 and sw2 respectively and you want a device in vlan A on sw 1 to communicate with a device in vlan B on sw 2. As both switches are L2 only you need a L3 device( router) to route the packets between the vlans which are broadcast domains but also different subnets.

To link the router and the switches you can simply indeed use an acces port on each switch going to a routed port in the corresponding subnet on the router.

Now what if you have only one switch  with multiple vlans  then you can also use 2 access ports in each vlan going to routed ports on the router if you have only 2 vlans but this is not scalable and you will be limited also by the number of routed ports available on the router.

So in this case you will use a trunk on the switch linked to physical port on the router and use subinterfaces with trunking to carry the different vlans on the same physical media.

Is it a little bit clearer now ?

Regards.

Alain.

Don't forget to rate helpful posts.

Don't forget to rate helpful posts.

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.

Nik

HTH,
Niko

Harmont12345
Level 1
Level 1

Can you tell me if situation described below is theoretically correct?

Lets imagine that no networks are splitted. So broadcast is always limited to the switch from which this broadcast came. If this is an unknown unicast from the same network, then again it's limited to the switch where it came from and is flooded to all ports in that VLAN.

Now if it's a unicast from another network then it goes to the router through trunks. Router knows where destination network is located, sets destination MAC accordingly and sends it back. 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.

I know that each packet will be tagged here by design, since these are trunks. But in fact, none of the switches will need to use this tag in this situation. Correct?

--- Nikita Andreev

--- Nikita Andreev

Hi Nikita,

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.

Regards,

Hari

Your understanding is right. In this particular scenario, we don't need tagging.

That's what I wanted to know when I started this conversation.

The switches are not smart enough to identify situation and use the tagging accordingly.

Switches are not, but network admin is smart enough to configure link as an uplink port ( if there was such port type ). If you need VLANs, but you don't need tagging it would be rather beneficial to have such option. I conclude that Cisco simply doesn't have that feature and tag all packets no matter what, for simplicity.

--- Nikita Andreev

--- Nikita Andreev

Can someone else confirm our conclusions?

--- Nikita Andreev

--- Nikita Andreev

Hi everybody,

i want just to remind a simple but important rule... We always need a tag if a val is in place AND this is a non-native VLAN AND we are using DOT1Q with its default values.

Having said this, i think that if out of the access switch there is an IP Phone (a kind of switch) and a PC, the fact with need a trunk to encapsulate Voice and Data VLANs would suggest tags here too.

have a nice day

Alessio

Hello,

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).

HTH

Nik

HTH,
Niko

Agree.

--- Nikita Andreev

--- Nikita Andreev

Harmont12345
Level 1
Level 1

One more thing I realized, is that when router receives the packet and sends ARP to look for destination MAC, all switches would have to flood all ports in all VLANs for router to find it. And it would break VLAN concept in its core - broadcast traffic has to be limited to the particular VLAN.

I guess it was explained in the following post but I didn't understand it in the way I described above:

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.

--- Nikita Andreev

--- Nikita Andreev
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: