Hub/switch auto negotiation
Mike Tomlinson
[crossposted to demon.tech.pc, uk.comp.os.linux and demon.tech.unix]
At work, our departmental network has three 24-port Cisco Catalyst 2900
switches hanging off our router. Those are managed by or organisation's
CIS department, who have a policy of disabling auto-negotiation on all
ports "as it's caused lots of problems in the past". Ports are
therefore configured to be fixed to 100Mbps full duplex, or for older
kit, 10Mbps half-duplex. Cabling is all new Cat5 UTP.
For political reasons, we don't have telnet access to the switches, so
reconfiguring them is a matter of liaising with Computer Services.
We have problems with various bits of kit connected to ports configured
at 100Mbps. It's a mixture of Windows, Sun, Alpha, and Linux kit, and
the problems usually manifest as poor network performance with lots of
collisions or 'carrier lost' messages showing in ifconfig
{eth0|tu0|le0}.
As an example, today I upgraded a RedHat6.2 box to RedHat7.1. This
installed a new driver for the 3Com 3C905TX network card, which promptly
started flagging errors in /var/log/messages together with long pauses
in machine operation ("eth0: Transmit error, 0x82", which according to
http://www.scyld.com/network/vortex.html is a half/full duplex
misconfiguration, and pages of 'dirty buffer' information written to
console.) If I use mii-diag (a utility provided by the scyld website
which allows one to configure the card), and lock the card to 100Mbps
full duplex instead of the driver default of auto-negotiation, the
errors and pauses go away.
Sometimes, if I watch the status LEDs on the Cisco switches, I'll notice
one flash orange instead of green very briefly. I haven't checked, but
assume this to indicate loss of carrier.
Has anyone any suggestions, and more specifically, would we be better
off arranging for the normal (NWay) autonegotiation to be enabled on the
switch ports, instead of them being locked to 100Mbps? I can provide
much more detail if required, but am hoping for feedback from people who
have seen this sort of problem before.
Many thanks.
--
"Security-wise, NT is a server with a 'Kick me' sign taped to it."
- Peter Gutmann
Karl Heyes
<mi...@jasper.org.uk> wrote:
> [crossposted to demon.tech.pc, uk.comp.os.linux and demon.tech.unix] At
> work, our departmental network has three 24-port Cisco Catalyst 2900
> switches hanging off our router. Those are managed by or organisation's CIS
> department, who have a policy of disabling auto-negotiation on all ports "as
> it's caused lots of problems in the past". Ports are therefore configured
> to be fixed to 100Mbps full duplex, or for older kit, 10Mbps half-duplex.
> Cabling is all new Cat5 UTP. For political reasons, we don't have telnet
> access to the switches, so reconfiguring them is a matter of liaising with
> Computer Services. We have problems with various bits of kit connected to
> ports configured at 100Mbps. It's a mixture of Windows, Sun, Alpha, and
> Linux kit, and the problems usually manifest as poor network performance
> with lots of collisions or 'carrier lost' messages showing in ifconfig
> {eth0|tu0|le0}.
You should have auto neg on, only fix it to a speed/duplex when there's a
problem.
Also I think the cisco 2900 has an STP (Spanning tree protocol) problem with
3com cards. I don't remember where the problem actually is but if you can
disable the STP on the switch!.
karl.
Paul Baker
>who have a policy of disabling auto-negotiation on all ports "as it's
>caused lots of problems in the past".
I can't answer the question, but I have also been told the above ("pile
of pants" was the technical term used!) The problem did manifest itself
on more than one occasion (Cards in PCs/servers being fixed at 100Full,
yet the switch (Baynet in our case) resolutely refusing to autonegotiate
to anything other than 100Half :( )
--
Paul
Colin McKinnon
news:s3BIJPAd...@jasper.org.uk...
> We have problems with various bits of kit connected to ports configured
> at 100Mbps. It's a mixture of Windows, Sun, Alpha, and Linux kit, and
> the problems usually manifest as poor network performance with lots of
> collisions or 'carrier lost' messages showing in ifconfig
> {eth0|tu0|le0}.
Top of my list of things to check would be cable quality and length. From
the sounds of it you work in an organisation which should be able to support
at least one able network technicion and LAN analyser - you need to get them
to check each and every cable.
I'd also try collecting error/collision rates at 10 minute samples over a
week to see if there is any pattern. If nothing else you can wave it under
the IT manager's nose.
HTH
Colin
Michael Salem
usual, this is a mixture of material of varying ages, but probably
mostly quite old.
H.8 Full Duplex versus Half Duplex ethernet
Q: Should I configure my ethernet equipment to operate in full-duplex
or half duplex mode?
A: The list has discussed this topic several times; and there is a
great deal of anectdotal evidence to suggest that full duplex ethernet
connections often _decrease_ network performance. This seems counter-
intuitive, what is the explanation?
A "normal" half-duplex ethernet has a very simple flow control
mechanism - the collision. If a collision happens, retransmissions are
handled at the physical layer, i.e. by the electronics of the ethernet
equipment. This happens very quickly, i.e within microseconds.
The ethernet full duplex flow control standard is IEEE 802.3x. In
order for this to work, _each_ device on the network must support
802.3x including NICs, switches, etc. The vendors seem to disagree on
the interpretation of the spec, however. See
http://www.nwfusion.com/netresources/0913flow.html for details and
vendor finger-pointing.
If the physical level 802.3x flow control is not working properly, a
busy ethernet may drop packets. In this case any retransmissions must
be handled at the protocol level, i.e. in software (the OS of the
network device). This happens _much more slowly_ then collision
handling. TCP/IP is very robust in this case, retransmissions occur
within 1/2 second or more (an eternity at wire speed!). Some protocols
are very poor in this regard, i.e. NFS over UDP. Some protocols have
no provision at all for retransmissions, for example RIP broadcasts,
SAP broadcasts, or any multicast protocols - any dropped packets are
lost forever.
[Thx Joe D., Hansang Bae, Arthur B., Mike A. and probably lots of
other people.]
Please note that full duplex ethernet _can work_ as advertised - it
just requires interoperability testing to make sure that _all_ of the
equipment on the wire is playing by the same rules.
>You need anywhere from 4 to over a dozen stations to reproduce
>problems that can be caused by full duplex (if there are any with
>your hardware). Most of our links are half duplex because they fail
>stress test at full, but I have stress tested full duplex between
>Foundry's BigIron switch, and Intel cards and so I leave those set at
>full duplex. (BTW: I highly recommend FoundryNetworks for anyone who
>needs a 10/100 or especially gigabit layer 3 switch that does IP, IPX,
>and Appletalk).
>
>Also, even though I do have some of our servers on full duplex now,
>about the best we get is a few % in performance as most of the
>traffic is one way... But when the link is unreliable (Intel card
>to a Bay/Nortel 350/450 for example), performance sometimes suffers by
>several hundred % when under a stress test.
[thx John Lauro]
And some final thoughts...
[SNIP]
>FDX fails just when needed most, under heavy stress. Under lighter
>loadings one can not tell the difference between FDX and HDX. Very
>often the large transfers are unidirectional, they are file
>transfers, and in those cases FDX buys almost no advantage. Backbones
>are the major beneficiaries of FDX, not workstations, because the
>traffic tends to be bidirectional.
[SNIP]
>the complete FDX path must be properly dealing with FDX traffic or the
>flow control messages (PAUSE packets) will not get through to the
>offending transmitter, if they get through at all with congestion. There
>is no good reason to think PAUSE packets are economical of network time
>since they say wait multiples of 512 bit times (contrast to a typical
>collision interval of 100 bit times) and the amount of waiting is a
>vendor's choice rather than dynamic sensing of the network moment by
>moment.
[thx Joe D.]
Hope this is of interest,
--
Michael Salem
John Chapple
>installed a new driver for the 3Com 3C905TX network card, which promptly
>started flagging errors in /var/log/messages together with long pauses
>in machine operation ("eth0: Transmit error, 0x82", which according to
>http://www.scyld.com/network/vortex.html is a half/full duplex
>misconfiguration, and pages of 'dirty buffer' information written to
>console.) If I use mii-diag (a utility provided by the scyld website
>which allows one to configure the card), and lock the card to 100Mbps
>full duplex instead of the driver default of auto-negotiation, the
>errors and pauses go away.
>
>Sometimes, if I watch the status LEDs on the Cisco switches, I'll notice
>one flash orange instead of green very briefly. I haven't checked, but
>assume this to indicate loss of carrier.
>
>Has anyone any suggestions, and more specifically, would we be better
>off arranging for the normal (NWay) autonegotiation to be enabled on the
>switch ports, instead of them being locked to 100Mbps? I can provide
>much more detail if required, but am hoping for feedback from people who
>have seen this sort of problem before.
Don't have any great experience, I'm afraid, but have you tried 3com's
Transend? It's a network monitoring ultility that'll amongst other
things <g> will stress test a network & subnets. Its free BTW.
Forcing 3com cards to use 100Mbits per sec has always ended in tears on
my (very) small network. Actually I've totally bolloxed more than one
905 by misconfiguring: so much that I had to send it off to 3com!
IIRC later 3com cards 905b & c had up at to 20% better performance.