Do you lose a lot of bandwith over a trunk port (vs access port)

[keithsauer507]

Hi, I have a 3750g connected to a "core" switch stack of 7 other 3750g's via 2 GigE ports in a trunk.  This is currently in a switchport mode access port-channel so only the default vlan data is sent over.

Now we have a need due to physical location of these switches, to allow vlan20 (DMZ) from this 3750g to the switch stack.  I will configure a few ports on the switch stack for vlan20 and they need to be able to talk to the stand alone 3750g.

To do this I will change the port channel on both endpoints to

switchport trunk ecapsulation dot1q

switchport mode dynamic desirable

also making the appropriate change on the interfaces belonging to this trunk.

My question is, now that its a trunk port that carries multiple VLANs, how much is the bandwidth reduced on that 2gbps link?

I have a very active VLAN (10) on the stand alone switch, but on the core I'm not going to be assigning VLAN 10 to any ports.  So does traffic from VLAN10 even come across the trunk (wasting bandwidth) if no ports on the core side are assigned to it?  I really just need vlan 1 and 20 (for now).

So just concerned about bandwidth, that is all.

[cadet alain]

Hi,

just use this command on the trunk links:

switchport trunk allowed vlan 1,20

when you need another vlan going over this trunk then edit this command accordingly.

Regards.

Alain

Don't forget to rate helpful posts.

[keithsauer507]

Ok so for the port channel config, use this right:

interface Port-channel11

switchport trunk encapsulation dot1q

switchport mode dynamic desirable

!

Then for each interface belonging to this port channel use this:

interface GigabitEthernet1/0/1

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,20

switchport mode dynamic desirable

channel-group 11 mode active

end

I thought I tried this in a lab and once I did that I lost connection to the switch I was SSH'd to.  To me that didn't make sense because switch management should by default be in vlan 1.  Maybe I did something out of order and I can try it again.  This time with a console cable as backup .

[kcnajaf]

Hi Keith,

I wouldn't assume this will create much traffic on the trunk link. Since your are using dot1q encapsulation this would be add additional 4 byte TAG field to the ehternet field on the trunk link to identify the vlan information.

If you dont want to a particular vlan to be send accross a trunk interface you can limit that vlan on trunk interface with "switchport trunk allowed vlan x" to allow only the vlan which is required.

Also you could enable VTP pruning. VTP pruning enhances network bandwidth use by reducing unnecessary flooded traffic, such as broadcast, multicast, unknown, and flooded unicast packets. VTP pruning increases available bandwidth by restricting flooded traffic to those trunk links that the traffic must use to access the appropriate network devices. By default, VTP pruning is disabled.Make sure that all devices in the management domain support VTP pruning before enabling it

Regards

Najaf

Please rate when applicable or helpful !!!

[keithsauer507]

Najaf KC,

Network consists of 3750's  (G's, standards, X's)

and a 3560X.

If one supports VTP, they all should.

To enable it and not risk any network downtime / interruptions... would you start at the core switch and then work your way out to ancillary switches?

[keithsauer507]

Err... vtp is already enabled on our core and two ancillary switches.  Just the one 3750 I plan on changing the trunk link to needs to be enabled as a client.  I already checked and its configuration revision is only 2 so it should not overwrite the core when enabled.

CORE:

sh vtp status

VTP Version capable             : 1 to 3

VTP version running             : 2

VTP Domain Name                 :  ******masked*******

VTP Pruning Mode                : Enabled

VTP Traps Generation            : Disabled

Device ID                       : 6416.8dc9.6080

Configuration last modified by 0.0.0.0 at 10-9-12 13:00:52

Local updater ID is 10.1.*.* on interface Vl1 (lowest numbered VLAN interface found)

Feature VLAN:

--------------

VTP Operating Mode                : Server

Maximum VLANs supported locally   : 1005

Number of existing VLANs          : 17

Configuration Revision            : 19

MD5 digest                        : 0x77 0xF5 0x93 0x9F 0x32 0x10 0x9E 0xE4

                                    0x80 0x57 0x14 0xFA 0xE0 0xA9 0x3E 0x54

[kcnajaf]

Hi Keith,

Enabling VTP pruning on a VTP server enables pruning for the entire management domain. So it looks like you are fine here.

Regards

Najaf

Please rate when applicable or helpful !!!

[Richard Burts]

There may be several parts to the original question which we can address. In general I agree that making it into a trunk should not consume much bandwidth. Najaf has already pointed out that the data frames will become larger by 4 bytes, which is not a lot. Also the trunk will now be passing some frames for negotiation of trunking. But that should not consume much bandwidth either.

There was also some concern whether traffic from vlan 10 would go accross the trunk. In general the answer is no there should not be frames in vlan 10 going over the trunk if there are no destinations in vlan 10 over the trunk. There are a few circumstances where vlan 10 traffic could be sent over the trunk. In particular if the standalone switch is attempting to forward a frame and the destination mac address is not in the mac address table then the switch will flood the frame to all interfaces in the vlan and this would send traffic over the trunk. It is not very likely but if the question is could it happen then the answer is that it is possible.

HTH

Rick

[Douglas Holmes · Accepted solution]

I wanted to address your question regarding the use of bandwidth of an access port versus a trunk port.  On a trunk port you have vlan tagging.  On an access port you do not.  I would think that the tagging has minimal impact on bandwidth.  On an all Cisco Network I set my trunk links as follows (actual example):

interface GigabitEthernet 1/0/49

switchport trunk native vlan 907

switchport trunk allowed vlan 4,8,100,101,499,900-906,908

switchport trunk encapsulation dot1q

switchport mode trunk

The Native VLAN is a vlan that is used for inter switch communcation.  I have one vlan that is ued specifically for this.  It is not on the allowed list since it's traffic is sent untagged.  If your not using a native vlan command then VLAN 1 is the default native vlan.  You can see this with the "show interface trunk" command. 

Port           Mode             Encapsulation  Status        Native vlan

Gi1/0/49       on                802.1q           trunking           907

The Switchport trunk allowed command configures what vlan's are allowed across the link.  It cuts down on unnecessary traffic.  You can use the "switchport trunk allowed vlan add" or the "switchport trunk allowed vlan remove" to add or remove vlans as necessary.  If your not using vlan 1 for users (not recommended) then VLAN 1 doesn't need to be one of the vlans allowed across the trunk. 

The switchport mode command between Cisco deivces really should be trunk only.  After all you really don't want the port to negotiate?

VTP annoucements are only transported over trunk links.  Never over an access port.  I use one vlan for management, one vlan in suspended state for unused ports, and one for native.  No users on either.  For me vlan 907 is Native and 908 is for Management.  VLAN 666 is assigned to all ports that are not in use.  It is in a suspended state.   

239-AIS-3750-1#show vlan

VLAN Name                             Status    Ports

---- -------------------------------- --------- -------------------------------

1    default                          active

666  NOTUSED                          suspended

907  native                           active

908  MANAGE                           active   

[keithsauer507]

Ok so instead of switchport mode dynamic desirable on the port channel interface and the interfaces attached to it... I should specify switchport mode trunk ?

I've used dynamic desirable because it just "works", but I have a spare switch with nothing on it trunked to our core and I can play with that.

So if you don't specify switchport trunk native vlan, it assumes VLAN1 is native?

That IS our native vlan so we should be ok there.  I know perhaps not best practice but that's what it is right now.

Interesting idea using a suspended vlan for unused ports.  We typically shutdown interfaces that are not used.  I guess it's six of one and half a dozen of the other.

[keithsauer507]

I do see a switchport mode trunk configured.  Po4 is a 4 port trunk to a Cisco 5508 WLC.

#sh interface trunk

Port        Mode             Encapsulation  Status        Native vlan

Po4         on               802.1q         trunking      1

Po11        desirable        802.1q         trunking      1

Po30        desirable        802.1q         trunking      1

Port        Vlans allowed on trunk

Po4         1,5,172

Po11        1,5,20

Po30        1-4094

Port        Vlans allowed and active in management domain

Po4         1,5,172

Po11        1,5,20

Po30        1-5,10-11,20,55,66,100-101,172

Port        Vlans in spanning tree forwarding state and not pruned

Po4         1,5,172

Po11        1,20

Po30        1-2

[keithsauer507]

Changing from switchport mode dynamic desirable to switchport mode trunk works perfectly.

Thanks for that suggestion.