Hi Cisco Support Community.
I posted earlier about this but have not found resolution. However, I have learned some more about the problem.
Here is a portion of the network.
On switch gc2960, we want to have clients on vlan 29 and vlan 27. We are connected over trunk port between switch gc2960 and the stack ch3750.
We used to have it connected to the switch ch3550 but it exhibited the same issue... I plan to retire the 3550 switch so that's why we're on the 3750 now.
The connection is on a fractional T1, split out by Adtran 850 units at either end. Both devices are connected to the ethernet interfaces of their Adtran 850's. I don't know if this makes a difference, but the other units are connected via other means and work as expected.
When native vlan 29 is NOT set, we can ping, telnet, resolve dns, etc. but we simply cannot use any web browser (firefox or ie both). It times out when browsing to anything. I use netstat -a on the client pc and I see the outbound connections on port 80. I know that data is coming back to at least the unit ch3750. This is both to targets on the internet, as well as for things on other parts of our organization's network such as a print server web management interface.
When native vlan 29 is set at both ends of the trunk, we can browse the web using firefox, ie, etc as expected from client pc's on vlan 29 on the gc2960 switch. But vlan 27 clients get the issue where they cannot browse, but can ping, do dns, telnet, etc.
What I am thinking is: for some reason, the "high ports" are not getting back to the clients on vlan 29 or vlan 27 unless we set the native vlan.
Why on earth would this be the case? I am stymied by this. Thanks for your comments.
Wow! Excellent idea!
system mtu routing 1500 is set on both switches.
I can from the client pc on vlan 29 on switch gc2960 send packets up to 1472 bytes when native vlan is set to vlan 29 on the trunk port. More, and we receive an error that the packet needs to be fragmented.
When native vlan is NOT set to vlan 29, I can ping with packet sizes up to 1468 bytes. Anything larger than that is not returned (no error).
It does not seem that "system mtu routing" is something I can set on the 2960. Can you suggest how to set the mtu?
From a 3750 guide, should work anywhere (have not verified on 2960):
Catalyst 3750/3560 Series switches support an MTU of 1998 bytes for all 10/100 interfaces. All Gigabit Ethernet interfaces support jumbo frames up to 9000 bytes. The default MTU and jumbo frame size is 1500 bytes. You cannot change the MTU on an individual interface. You must set the MTU globally. Reset the switch afterwards for the MTU change to take effect.
Use the system mtu command to change the MTU for all 10/100 interfaces. This command only effects 10/100 interfaces.
3750(config)# system mtu 1546 3750(config)# exit 3750# reload
Use the system mtu jumbo command to change the MTU for all Gigabit Ethernet interfaces. This command only effects Gigabit Ethernet Interfaces.
3750(config)# system mtu jumbo 9000 3750(config)# exit 3750# reload
Note: Gigabit Ethernet ports are not affected by the system mtu command; 10/100 ports are not affected by the system mtu jumbo command. If you do not configure the system mtu jumbo command, the setting of the system mtu command applies to all Gigabit Ethernet interfaces.
Use the show system mtu command to view the mtu sizes after reload.
Switch# show system mtu System MTU size is 1546 bytes System Jumbo MTU size is 9000 bytes
Message was edited by: Jimmy Sands The post shows someone changing MTU on 2960
I have discovered the reason for the trouble I was having, this was not related to mtu or switch configuration.
We were connected from site to site over T1, using Adtran Total Access 850 units at both locations. Apparently these units do not pass 802.1q vlan tagged packets. The person I spoke with at Adtran said this is something intrinsic to all channel-bank equipment - I don't know if he means all Adtran brand units, or all channel bank units in general. Adtran suggested a hybrid solution involving a netvanta 3200 used in conjunction with the ta850 to resolve the issue.
In the mean time, we've elected to live without an appearance of the second vlan at this location.