Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations dencom on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Trunk port problem 1

Status
Not open for further replies.

McCisco

Technical User
Oct 29, 2006
81
US
I have a trunk port setup between a 2950 and a 4507. The connectivity between the two switches is very slow.

Thoughts


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~ THIS IS THE INTERFACE ON THE 4507~~

interface FastEthernet6/12
switchport trunk encapsulation dot1q
switchport trunk native vlan 2
switchport trunk allowed vlan 2,201,202
switchport mode trunk
speed 100
duplex full
spanning-tree portfast trunk
spanning-tree bpduguard disable
end
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ THIS IS THE INTERFACE ON THE 2950~

interface FastEthernet0/24
switchport trunk native vlan 2
switchport trunk allowed vlan 2,201,202
switchport mode trunk
no ip address
duplex full
speed 100
spanning-tree portfast trunk
spanning-tree bpduguard disable
end
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
..i dont see anything right off..
..i know this is redudant..but
...what does #show interface f0/24, 0/12 show..
...i think you can also append trunk to the end to get trunk information...
..any dropped packets..errors resets..etc;



..dont you want bpdguard on?

 
ThWhat about the "spanning-tree portfast trunk" - Could it be causing a problem?
 
Look at the output of "show interface". If you see CRC or other input errors on the Fast Ethernet interfaces, remove the "speed 100" and "duplex full" commands and let the interfaces autonegotiate properly.
 
I removed the speed and duplex statements from both ports and that seemed to fix the problem.

THANKS
 
This highlights an issue that I've been pointing out to people for a couple of years. Manually configuring your speed and duplex is a very bad idea on "modern" hardware. In your case, you had a duplex mismatch even though both sides were configured as full duplex. Unknown to you, one side was still setting itself to half duplex even though you had it set to full duplex.

It's a strange situation, but it happens all the time on certain hardware.
 
Really? I'll be. They don't teach you that in the cert guides. Good to know, jneiberger.
 
Yep, it happens all the time, and I'll tell you why. Autonegotiation is the only method mentioned in the Fast Ethernet standard. There is no mention of how a NIC (or switch port) is supposed to behave when the speed and duplex are manually configured. This has led to two different possible implementations:

#1: Disable autonegotiation and use the configured settings

#2: Continue to participate in autonegotiation but only offer the configured settings

The real problem is when you connect a NIC (or switch port) using option #1 to one using option #2. Typically, a device that participates in autonegotiation will drop back to half duplex if it doesn't detect an autonegotiating link partner. If it doesn't detect another device capable of autonegotiation it will assume that it is connected to a hub and drop back to half duplex, even if you have it configured for full duplex!

It happens all the time. The best way to go is to always use autonegotiation (on both sides!) and only use manually configured settings when you have a good reason for doing so.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top