Said Jeff Wojciechowski: > FastEthernet0/3 is up, line protocol is up (connected) <snip> > Full-duplex, 100Mb/s, media type is 10/100BaseTX <snip> > 5 minute input rate 2000 bits/sec, 3 packets/sec > 5 minute output rate 3000 bits/sec, 4 packets/sec > 0 runts, 0 giants, 0 throttles
It's unusual to see '0 runts' on the full-duplex end of a duplex mismatched link. The number is typically very high because the half-duplex end will abort transmission immediately when it detects an incoming frame from the full-duplex peer. Each time it aborts before completing the 64th byte after the preamble and SFD, this counter will increment. It's possible however, that because of the very low data rates, you've never triggered a collision so early in one of your link partner's transmissions. Try setting, your interface to auto/auto. If it comes up as 100/Full, then you almost certainly had a mismatch. Said Ken Matlock: > Keep in mind on a lot of gear (Cisco included) that at 10/100 speeds, > half-duplex is the default for duplex negotiation failure. This means > if you hard-set one end to 100/Full and the other is auto, 99% of the > time the auto side will come up 100/Half. The behavior Ken described is often viewed as a problem, but it is correct. A port that *refuses* to negotiate is indistinguishable from a legacy device that *can't* negotiate (like a hub). Half duplex is the only reasonable response for a link partner that's configured to attempt autonegotiation with such a device. > 1gb speeds 'Full' is the default, but we still leave those ports at > auto, and let the FLP's handle the negotiation. Autonegotiation is required for gigabit operation, so this is a reasonable policy. But there's a gotcha here: You may have clients which you'd prefer get no service, rather than getting a 100Mb/s link. If these clients, which were intended to have a gigabit connection experience a cable failure on pins 4,5,7 or 8, they'll negotiate 100Mb/s instead of 1000Mb/s. In those cases, 'speed 1000 auto' or 'speed 1000' may be appropriate. /chris _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
