Re: Trunk port Question

qiblatain1400 · ‎03-15-2011

Dear All,

In which scenario, We can use those Switch Ports which are connected to the Hosts as Trunk Ports ?

Normally all those ports of Switch which are connected to the Hosts are in Access Mode.

As per my knowledge and understanding, for the security point of view & for congestion avoidance, the Switch ports connected to the Hosts should be in the Access Mode not the Trunk Mode.

Am I correct ?

Apurva Kulkarni · ‎03-15-2011

Hi Naveed,

We can make an interface connecting to host as a trunk link only if we want that host to receive data from multiple vlans.

Usually, on a switch we configure vlans to logically devide the users and to avoid flooding all the users with all the information from multiple vlans which they do not need and which causes unnecessary burden on the ports carrying traffic.

Also, as you have mentioned it serves the purpose of securing the data, as the traffic from other vlans would not be sent on an access port configured to access some particular vlan.

Only the links connecting between the devices would be configured as trunk links so that they can carry the information from all vlans and later send it out on the access ports depending on the vlan.

Hope this answers your query.

ranraju · ‎03-15-2011

NIC on the host ususally does not understand the tagged frames from the switch, and if we make the port as trunk, the host receives these tagged frames and also spanning tree bpdu's, and most of the time it just drops these frames, as it does not understand tagging. And if it does understand tagging then it might cause a security issue.

Well, the ports connected to servers are made trunk most of the time, but never seen a port connected to a PC/Host made trunk, as its not recommended.

Peter Paluch · ‎03-15-2011

Hello,

NIC on the host ususally does not understand the tagged frames from the switch

I would like to argue with this a little. From the perspective of a NIC, the tagged frames are ordinary frames having the EtherType set to 0x8100, nothing more. Absolutely no special support on the NIC is necessary, apart from the ability to accept slightly oversized frames (up to 1522B).

It is the operating system which does not usually register a driver for the protocol number 0x8100 and thus it does not process the tagged frames. Note that an operating system usually registers drivers for protocol numbers 0x0800 (IPv4), 0x0806 (ARP), 0x86DD (IPv6), and the frame tagging is from this perspective just another protocol requiring another software driver for the protocol number 0x8100.

It is true that some NICs do have hardware support for 802.1Q frame tagging, however, the goal of that support is to offload the processing of 802.1Q tags, much similar to TOE engines offloading the TCP operations on the NIC. However, even without a hardware support on the NIC, every NIC understands a tagged frame - because it is a frame just like any other. It is just the operating system that needs to know how to process the payload of such a frame.

Best regards,

Peter

ranraju · ‎03-15-2011

To be more specific, yes there are NICs on which you can enable the support for 802.1Q frames with vlan information in it. Rather than me saying "NIC on the host usually do not understand the tagged frames from the switch" - instead if I put it this way then there is less ambiguity: "If a port has a 802.1Q-compliant device attached to it then it would understand the tagged frames, if there is a device on the port that is not 802.1Q-compliant then it will not understand the VLAN tag and will drop the frame"

Well, I would also acknowledge the fact that the operating system has to register drivers for certain protocol numbers, and it also has to register a driver for the protocol number 0x8100 which is for VLAN-tagged frame (IEEE 802.1Q). Without this it does not process the tagged frames, and hence get dropped at the host. --- and yes all of this is a host dependent functionality.

"........However, even without a hardware support on the NIC, every NIC understands a tagged frame - because it is a frame just like any other. It is just the operating system that needs to know how to process the payload of such a frame."

To add to this, a tagged frame cannot be just another frame, a normal frame would have only the layer2 information along with the Ethertype. But a 802.1Q frame will have an 802.1Qtag in its header along with the layer2 information and the Ethertype. So unless the PC or host has not enabled/registered the driver for 802.1Q, it will not be able to understand the dot1q frame header, only if this feature is enabled only then the PC will be able to comprehend what the frame is about.

So, coming back from the functionality of the NIC to the actual question on the post.." In which scenario, We can use those Switch Ports which are connected to the Hosts as Trunk Ports? "

As said, we have seen ports connecting to the servers are made as trunk ports, but unless you have a specific need to have the PC receive more than one vlan data/information (maybe for monitoring traffic), you can configure it as trunk, depending on the capabilities of the host.

Regards,

ranraju

Peter Paluch · ‎03-15-2011

Hi ranraju,

I hope I did not offend you in any way - please accept my apologies if I did. I certainly did not intend to do so.

For a couple of years, I have been trying to eradicate a widely spread misunderstanding that the 802.1Q frame tagging requires a hardware support. As we have both agreed, it does not. Perhaps I've reacted too harshly - sorry for that

To add to this, a tagged frame cannot be just another frame, a normal 
frame would have only the layer2 information along with the Ethertype. 
But a 802.1Q frame will have an 802.1Qtag in its header along with the 
layer2 information and the Ethertype.

This is a matter of viewpoint. You may indeed consider the 802.1Q tag as a part of the header. But an equally valid viewpoint is that the header ends with the EtherType (currently set to 0x8100), and the actual tag (3 CoS bits, 1 CFI bit, 12 VID bits) is already inside the frame payload. Actually, this is exactly what makes the tagged frame perfectly compatible with all Ethernet implementations. Whether the higher software is able to interpret the payload correctly - that's another issue.

Best regards,

Peter

rparames · ‎03-15-2011

Hello Peter,

Nice point you made. It is actually the software that needs to be tweked in most cases inorder to process tagged frames

As an example:

http://www.intel.com/support/network/sb/cs-005897.htm

A lot of people still believe that it is a limitation of the NIC card.

Regards,

Rahul

rparames · ‎03-15-2011

Hello Naveed,

Good questions, In the environment we have been operating so far all end host connected to switch were PC's or server and these devices did not have the need to communicate on different vlans . So they sent untagged packets and hence we configure the ports to be access ports rather than trunks.

With the introduction of server virtualizaton , server manufacturers are enabling dot1q tagging along with other features on the servers that requires the port connected to the server to be trunk instead of access ports

http://www.vmware.com/pdf/esx3_vlan_wp.pdf

(PS: I have not gone through the information provided in the link)

In all other senarios we recommend that end ports be access instead of trunks for the same reason you have made.

Regards,

Rahul