>The more I think about it, the more I realize that this whole mess >really comes about because some geniuses insist on still forcing link >speed and duplex instead of letting 802.3u autonegotiation do its job. >I guess Sun contributed to the current mess at one time by shipping >buggy 100Mbit implementations that didn't autonegotiate/NWay properly.
As did many others; I remember we had tons of broken Cisco gear which needed firmware upgrades before it would work correctly. But even now I'm told Nortel recommends fixing the speed in their switches (which tells me that you should avoid their stuff at all cost) >I suspect that the problems that people are mostly concerned about are >where the link duplex is incorrectly set. Again, probably because one >side is trying to autonegotiate, but the other side is set to 100 full >fuplex, forced, with 802.3u autonegotiation specifically disabled. The >network engineers that insist on continuing to do this should probably >be thwacked, but that's out-of-scope for this case. :-) I doubt the >speed selection is nearly so much a problem. Perhaps dladm/ndd can print a message to the effect of "Disabling autonegotiation indicates that you have people working in your networking organization with an IQ under 80". >In any case, there is nothing inherently bad about half duplex (other >than it may be performance limiting to a certain extent), as long as >_both_ sides agree on the duplex setting. It is perfectly reasonable to >have half duplex negotiated when a hub is inserted into the link, for >example. > >The thing is, when you have it misconfigured, usually you'll be able to >tell by, for example, getting collisions on a full-duplex link, or >getting late collisions on a half duplex link. This situation can >easily be correlated, and is a far better indication than just naively >looking at the duplex state alone. Collission on a full duplex link? Wouldn't this be CRC errors (because as soon as you start sending the other side will stop and you will happily send your packet but the other packet will be short; how is this detected. >And this is precisely the kind of analysis that FMA should be doing for >the customer, rather than just leaving breadcrumbs in the syslogs. When >FMA figures out that a misconfiguration likely exists, then _it_ can log >the specific analysis rather than just this random clue "hey your link >changed". (One could even try to be clever and have FMA self-repair >this situation!) Absolutely; FMA could say "detected late collissions on half-duplex link, forcing full-duplex". Not sure how to go down to half-duplex. Casper
