how many trunks are allowed in a switch ?

[SJ K]

Hi all,

Today I have came across NIC card that is able to tag VLAN as well as the tagging of VLAN in VM environment from the guest OS nic card.

I believe sometime tagging a VLAN on the host/guest devices is necessary as oppose to configuring the VLAN information in the switch

Q1) Therefore in the example listed, i believe that the physical connectivity between the host device's ethernet adaptor port and the network switch port have to be trunked -- since the host device's ethernet adaptor might be carrying multiple VLAN frames  -- am i right ?

Q2) Assuming this particular network switch(1) is being uplink to another switch(2) and the 2 switches will also requires to exchange VLAN frames.
Can I still create a trunk from switch(1) to switch(2) ?  bearing in mind that I have create a trunk earlier from my host device to switch(1)

Q3) In the event that switch(1) receive a VLAN tagged frame from the host device (A) via the 1st trunk -> how does it knows whether or not it need to transverse up another trunk link to switch (2) ?   

Does the frame get untagged by the receiving switch (1), see the mac address of the destination -> realise it must go through the uplink trunk port --> tag back the original vlan --> and send out via another trunk port to switch (2) ?

Q4) What happen when a switch receive a vlan tagged frame via its trunk port ? Does it need to untagged the VLAN information from the frame in order to look into the frame's destination mac address to check against the mac forwarding table ? Does it tagged back the VLAN information when it has determined to send the frame to another access port of that particular VLAN ? Where does the switch get the VLAN information from then, since it is already untagged ? or it is tagged at the access port when the particular frame is send there.

Regards,
Noob

[Jon Marshall]

q1) some servers do use tagging yes. It is more common now with virtualisation where you can have multiple virtual servers in the same physical chassis

q2) every port on your switch can be a trunk if that is what you want. There is no limitation on the number of trunks you can create.

q3) same as with any frame, It is the destination mac address that matters to a switch and if that mac address is reachable via the trunk to other switch it is sent there.

So yes what you describe is what happens.

q4) if the port is an access port ie. not a trunk it is not tagged when it is sent out of that port.

If the port is a trunk then yes the switch will tag the frame with correct vlan ID and send it out.

As to where it finds the vlan information I have always assumed it is from the mac address table as it is recorded in there.

Jon

[SJ K]

Dear all,

Thanks for your valuable answers.

As peter have mentioned earlier, there is no need to untagged a VLAN to see the src/destination mac address.

Now this make me think of the whole ingress and egress process of VLAN tagged frame, please correct me if I am wrong..

Scenario 1

1) Host1 (mac -a.b.c.d), send an untagged frame to fe0/1 of switch which is configure as an access port of VLAN01

2) Frame is received on the switch and tagged with VLAN01

3) Src Mac Address of Host1 is recorded in the Mac address forwarding table as

[a.b.c.d], [fe0/1], [VLAN01] -- q1) does it store or need to store the VLAN01 information here?

4) No untagging required, destination mac address determined , assuming to fe0/4

5) Since mac address is unique -- q2) does the switch still need to verify if fe0/4 belongs to VLAN01 ? what i meant is if host1 have determine host2 mac address through arp request, it means that they belong to the same VLAN, in that case when host1 send a frame to host2, does the switch still need to verify in the mac address table that the destination port belong to the correct VLAN ?

6) fe0/4 which is an access port receive the frame - q3) does it untagged the frame before sending out to host 2? where is the untagging done ? on fe0/4 itself before sending out or before sending to fe0/4 ?

 

Scenario 2

1) Host1 (mac -a.b.c.d), send an untagged frame to fe0/1 of switch which is configure as an access port of VLAN01

2) Frame is received on the switch and tagged with VLAN01

3) Src Mac Address of Host1 is recorded in the Mac address forwarding table as

[a.b.c.d], [fe0/1], [VLAN01]

4) No untagging required, Dst mac address is determined , assuming to fe0/5 and fe0/5 is a trunk port/uplink to another switch named switch2 and connected on fe0/5 as well.

5) frame is send from switch1 fe0/5 and up to switch2 fe0/5

6) switch2 fe0/5 check the frame and see if the VLAN is on allowed list.
Dst mac address is determined and mac address table look upon into on switch2, assuming to be also to fe0/4 in switch2

7) fe0/4 which is an access port receive the frame, untagged the frame as required and send it to Host 2

Scenario 3

1) Host 1 send a tagged frame of VLAN01 to trunk port fe0/1 which is configured as a trunk port in switch1

2) fe0/1 received the frame, check if it is in the allowed vlan list

3) Src Mac Address of Host1 is recorded in the Mac address forwarding table as
[a.b.c.d], [fe0/1], [VLAN01]  -- q1) over here fe0/1 is a trunk port, hence there might be many other entries with fe0/1 but different VLAN (assuming my host1 is a esx machine), am i right ?

3) without untagging the frame, the destination mac is determined and and mac address table checked, assuming to be to port fe0/4 in the same switch -- q2) same question as prior, does the VLAN of fe0/4 need to be check to ensure that it is in the same VLAN as of the frame ?

4) frame is send to access port fe0/4  -- q3) does it untagged the frame before sending out to host 2? where is the untagging done ? on fe0/4 itself before sending out or before sending to fe0/4 ?
 

Q4) For all my 3 scenarios above, are they right ?

==============================================================================

Last question, Peter mentioned

Once the VLAN membership of a frame has been determined, it then depends on the hardware construction of a switch where this information is kept while the frame is processed. This could be either some hardware register that keeps the VLAN information for the frame, or some control structure associated with the frame during its processing time.

From all the scenarios above, it seems like there is no need to untag the frame to check the destination mac address ? and the vlan tag stored together with the frame.

Q5) So what does Peter meant when he mentioned "where this information is kept while the frame is being processed", isn't the membership information/VLAN tagged stored together with the frame, there is no untagging done. Also, once it is untagged to be send to the destination, there is no need to tagged the frame back.  

Why would it need to be store elsewhere while the frame is being processed ?

Regards,
Noob

[Peter Paluch · Accepted solution]

Dear friends,

Please allow me to join and add my two cents.

Q1) You are asking if the link between the switch and the NIC that performs VLAN tagging should be a trunk link. Yes, absolutely, in such case, it must be configured as a trunk on the switch. The switch itself does not care why the frames are tagged - whether the device on the other end is another switch with a trunk port, or it is a server that is capable of VLAN tagging. It just needs to be prepared for the tagged frames to come in, and be allowed to send tagged frames out. That's why the link needs to be a trunk link.

Q4) This question basically focuses on how does a switch determine and keep the information about the VLAN the frame belongs to while the frame is being switched.

Well, if the frame came in through an access port then it is the configuration of the access port itself that determines the VLAN into which the frame belongs (the switchport access vlan vlan-id command). If the frame came in through a trunk port then either the frame carries a VLAN tag that determines its VLAN membership, or the tag is missing and in that case, the frame is assigned to the native VLAN of the trunk.

Once the VLAN membership of a frame has been determined, it then depends on the hardware construction of a switch where this information is kept while the frame is processed. This could be either some hardware register that keeps the VLAN information for the frame, or some control structure associated with the frame during its processing time.

Does it need to untagged the VLAN information from the frame in order to look into the frame's destination mac address to check against the mac forwarding table ?

No. If you look up the format of a VLAN tagged frame (here, for example), the destination and source MAC addresses are in their original place. The VLAN tag is inserted after the address fields so the switch does not need to untag the frame - it only needs to analyze the value of the VLAN tag to know the VLAN the frame belongs to.

As to where it finds the vlan information I have always assumed it is from the mac address table as it is recorded in there.

Jon, this wouldn't be right. Keep in mind that besides switching, a switch must also learn MAC addresses and store them into the MAC address table with the appropriate VLAN information already determined. In other words, a basic MAC address table row consists of the following fields (regardless of their order): MAC address; VLAN in which the MAC address resides; switchport where this MAC address is attached. The switch performs learning using source MAC addresses as the frames come in, and the VLAN membership must be determined at that stage, otherwise the switch could not fill in the MAC address table for a newly discovered source MAC correctly.

The determination of the VLAN where the frame belongs is done at the moment of its arrival, either based on the VLAN tag of the frame, or on the configuration of the ingress port. Once the VLAN membership has been determined, this information is stored with the frame in a control structure most probably separate from the frame itself, provided by the switching hardware of the switch. Recall that beyond VLAN membership, Catalyst switches also determine the priority of the frame and they represent it using a so-called internal DSCP value. They do this even if the frame carries a non-IP payload (based on CoS-to-DSCP mappings). Obviously, the DSCP information cannot be carried nor looked up in such frame at all - therefore, it is logical to assume that this information, along with many more including VLAN, is stored in the switch separately during the time the frame is processed. How exactly that is done - that's the intellectual property of the manufacturers that designed the switching hardware, as this has to do quite closely with its performance and features.

Best regards,
Peter

[Jon Marshall · Accepted solution]

Peter

The determination of the VLAN where the frame belongs is done at the moment of its arrival, either based on the VLAN tag of the frame, or on the configuration of the ingress port

I wasn't referring to how the switch works out what vlan a received frame is in because as you quite rightly say that can only be determined when the frame is received either on a trunk or an access port.

I was referring, incorrectly,  to the actual forwarding of the frame ie. which port(s) to send the frame out of.  

And I was suggesting the switch can use the mac address table to not only extract the port information but also the vlan information for that port from the same table.

So if a frame with a destination unicast mac address comes into the switch it will, as you say, know which vlan the frame is and be able to record the source mac address and vlan information into the mac address table.

But it still needs to know which port(s)  to forward the frame out of and it would also need to verify that port was either in the same vlan if an access port or the vlan was allowed if a trunk port.

However on thinking about it using the mac address table wouldn't work because for ports with connected devices that the switch has not yet recorded the mac address there won't be an entry and if a broadcast is to be sent the switch has to know which ports to send it out of.

It does know this obviously but the information is not in the mac address table.

Related questions to this have come up before and I have spent many fruitless hours searching through Cisco documentation for how the switch actually handles all this internally but so far no luck.

Jon

[Peter Paluch]

Hi Jon,

However on thinking about it using the mac address table wouldn't work because for ports with connected devices that the switch has not yet recorded the mac address there won't be an entry and if a broadcast is to be sent the switch has to know which ports to send it out of.

Yes, that is one of nice observations showing that using the MAC address table to determine the VLAN membership is not the proper way of doing things. Two more counterexamples to reinforce this:

1. A switch can have a single MAC address learned in multiple VLANs at once. Just think of a router-on-stick connected to a switch over a trunk. Whatever frame this router sends, no matter which VLAN, will carry the same source MAC address. Looking up its MAC address in the MAC address table would return several VLAN IDs - clearly not helpful.
2. Lookups in the MAC address table are performed on the compound key of (MAC, VLAN ID). In other words, when a switch looks for the destination MAC address, it looks only in those rows of the MAC address table in which the VLAN ID matches the VLAN of the frame (a constrainted table lookup). So to restate this, you already know the VLAN ID before even doing the lookup - the VLAN ID is one of the inputs for the lookup - so there's nothing new to learn by this lookup in this aspect.

Related questions to this have come up before and I have spent many fruitless hours searching through Cisco documentation for how the switch actually handles all this internally but so far no luck.

I am not surprised. These are things very closely tied to how the hardware of a switch works. I do not suppose that common documents would go into such depth. Perhaps the information is not classified but to most people, it's not of particular interest, and it could differ between switching platforms.

Best regards,
Peter

[Jon Marshall]

Hi Peter

Yes, that is one of nice observations showing that using the MAC address table to determine the VLAN membership is not the proper way of doing things

Okay we are not talking about what vlan the frame is in, because, as already covered, that is determined when the switch receives the frame.

But doesn't your second point in the last post somewhat contradict the above statement ie. if the mac address lookup is a constrained lookup based on mac address and vlan ID then you are not determining the vlan ID of the frame but you are using the mac address table to determine the vlan membership of the ports.

As for documentation not being of particular interest to most people, it most certainly is to me :-)

Jon

[Peter Paluch]

Hi Jon,

But doesn't your second point in the last post somewhat contradict the above statement ie. if the mac address lookup is a constrained lookup based on mac address and vlan ID then you are not determining the vlan ID of the frame but you are using the mac address table to determine the vlan membership of the ports.

Personally, I would not put it this way. With regards to VLAN membership of ports, there is nothing to determine by the MAC address table lookup. A port's VLAN membership is always given by its configuration. The constrained lookup in the table only looks up the proper port to send the frame out from, but the port's VLAN membership is no longer a question at this point - if it wasn't in the same VLAN as the frame that is being processed, how could the frame's destination be learned on that port in that particular VLAN?

Best regards,
Peter

[Jon Marshall]

HI Peter

So the lookup using the vlan ID is only for optimisation and nothing else ?

It would make sense of course because as already discussed broadcast traffic cannot possibly use the mac address table to derive the correct ports.

When you are next at Cisco can you try and get any internal documents on switch architecture because it is one of those things that has always intrigued me :-)

Jon

[Peter Paluch]

Jon,

So the lookup using the vlan ID is only for optimisation and nothing else ?

If you are referring to the MAC address table lookup using the (Dest MAC, VLAN ID) key then the primary reason for using the VLAN ID along with the Dest MAC is to make sure that the VLAN remains contained - you are only looking for possible destinations in the frame's VLAN of origin. Even if there was a matching MAC address learned in a different VLAN, you would not use that entry, thereby ensuring that frames from one VLAN do not leak into other VLANs.

Best regards,
Peter

[Jon Marshall]

From an earlier post -

With regards to VLAN membership of ports, there is nothing to determine by the MAC address table lookup. A port's VLAN membership is always given by its configuration

and then -

Even if there was a matching MAC address learned in a different VLAN, you would not use that entry, thereby ensuring that frames from one VLAN do not leak into other VLANs.

These seem to be contradicting each other somewhat.

If the ports membership can be determined from the switch configuration then that could ensure frames from one vlan do not leak into another.

So there does seem to be a reason to use the vlan ID in the mac address table and this is to determine which set of ports can be considered in the lookup.

Perhaps I am just not quite understanding ?

Jon

[Peter Paluch]

Jon,

I hear what you are saying: If the switch can guarantee - using other means - that frames in a particular VLAN never flow out ports in other VLANs, what is the point of performing the destination MAC address lookup in the MAC address table using the compound (DstMAC, VLAN ID) key?

Quite frankly, I can only guess. With today's CAM/TCAM circuitry, you cannot speed up the lookup by including or omitting the particular VLAN ID in the search key, as the (T)CAM performs the lookup in parallel throughout its contents (if I got the TCAM primer right). In fact, I am starting to doubt that the lookup of the destination MAC address uses the VLAN ID at all because just as you said, the swich is capable of limiting the delivery/flooding of the frame just to the ports in the VLAN of the frame regardless of the information stored in the MAC address table - think of unknown unicast/multicast/broadcast flooding.

So at this point, I suggest we simply remain with the fact that the VLAN in which the frame is delivered and the egress port VLAN membership is both determined and confirmed at several points in the path of a switched frame. Whether referring to any of those places (port configuration, frame VLAN tag, VLAN ID in the MAC address table) provides you with a better switching performance ultimately depends on the construction of the switch, and I am not qualified to suggest any particular choice here.

It would be nice to have some Cisco guru who is well-versed with Catalyst or Nexus guts to enlighten us here... :)

Best regards,
Peter

[SJ K]

Dear all,

I am abit lost in the conversation between the experts here.

Can i check if the discussion is about the following below

1)  vlan membership is given by its configuration and not be referencing to the mac address forwarding table.

if receive by an access port, it is tagged with the vlan as according to what vlan the access port is in.if it is receive by a trunk port, then the vlan information is already tagged in the frame.

On this point above - am i right ? I think we are on the same page.

2) what good reason is the mac address table used to store vlan membership information for? since

a) frame aint untagged when received in the switch and doesnt need to be retagged

b) if a frame has already an destination mac, and by having the destination mac, it means that, the destinated egress port is in the same vlan of the frame
and hence the above discussion ?

Am i catching up with you guys or I am already way off the topic.

=================================================================

So can i assume that the VLAN lookup in the mac address table is just to make sure that the designated egress port of the destination mac, is in the same VLAN of the frame. That's all .  Am i right ?

Regards,
Noob

[Jon Marshall]

Sorry about all the confusion.

Firstly my comment about using the mac address table was only about the destination ports to send the frame out of.

However it is obviously not correct.

As Peter quite rightly pointed out it has nothing to do with learning the mac address to vlan mapping of a frame, that is done when the switch receives the frame and the mac address table is used to record that information, nothing else.

The simple fact is that this is largely internal to the switch and as you can probably tell not documented anywhere, or at least anywhere I have managed to find.

It's not a great answer but I can't really be any more specific.

I suspect, as Peter says, the information is held internally and that there is no direct access in terms of commands to see exactly what is happening.

Jon

[SJ K]

No worries, Jon and Peter.

1) I guess we can all conclude that vlan membership of frame is either base on the configuration of the ingress port or tagged already together with the frame.

2) The vlan membership of a port is via the switch configuration and the use of the mac address table to hold vlan information might not be that straight forward.

It might be use for performance or double verification purpose; to faster look up port associated with a destination mac address + vlan or to check if a particular designated port's vlan in the mac address table matches with the switch current vlan configuration of that port.

Am i right ?

Regards,
Noob