-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris Hoogendyk wrote:
>
>
> Ryan Novosielski wrote:
>> Chris Hoogendyk wrote:
>>
>>> Ryan Novosielski wrote:
>>>
>>>> I send this note every once in awhile, since I know around my workplace
>>>> there is a lot of confusion over it.
>>>>
>>>> Both ends of a network connection must be either hard-coded to the same
>>>> speed and duplex, or set to auto/auto. Any other combination will
>>>> result
>>>> in the end that is set to auto stairstepping down from fastest to
>>>> slowest until it finds a comparable rate, and WILL use half duplex.
>>>> So I
>>>> suppose to adjust my comments a little, if you are using 100/half on
>>>> one
>>>> end and auto/auto on the other, that will work, but I'd say it's not a
>>>> great habit to get into (and who uses half duplex on anything other
>>>> than
>>>> 10-base-T anyway?).
>>>>
>>>> Philip W. Dalrymple III wrote:
>>>>
>>>>> Our problem turned out to be a network hardware problem, the port
>>>>> that the
>>>>> SD was plugged into was at 100 not 1000 and maybe the server was at
>>>>> 1000 or the duplex was not matched.
>>>>>
>>> We routinely hard code both servers and the ports they are connected
>>> to in our switches switches.
>>>
>>> In my experience, Solaris servers typically manage negotiating
>>> alright, but we set the switch ports anyway. Alpha servers
>>> notoriously messed up autonegotiation and had to be hard coded to
>>> work reasonably well. We also had repeated problems with Windows
>>> servers. I resolved it on a few occasions, but since I was not the
>>> Windows admin, it kept getting put back and causing trouble which was
>>> always blamed on the network group.
>>>
>>> Anytime there is a problem of this sort, check the switch port
>>> statistics, and check the configuration on the computer end and on
>>> the switch end.
>>>
>>
>> We used to do this, however we no longer do unless absolutely necessary.
>> The reason for this is it ultimately screws up network installs for
>> machines that do not have a nvram setting to hard-code the speed/duplex.
>> There are many network adapters (mostly on older machines, but we're not
>> talking THAT old) that can only use autonegotiate for network booting,
>> meaning you're doing an install over a very ratty connection. Same works
>> fine with both ends set to auto.
>
> OK. We don't do net installs. So your situation is different.
>
> We handle ours on a case by case basis. So, if there were a machine that
> had problems, we would configure it as best fit that situation. I've
> found that the Solaris systems are robust enough that if the switch is
> fixed and the server is not, it will still find its way correctly to
> match the switch. But, we set them both fixed just to be sure.
We're getting off track here a bit, but it is probably a useful
discussion anyway. I've been told, and I've read, that a machine acting
in such a way would be counter to the spec for autonegotiate. I don't
have the document anymore, but the gist of it was that if one end was
set to auto and the other was fixed, the auto end would start from the
highest speed it was capable of and drop down until it found one that
worked, and that it would absolutely use half duplex. So according to
the spec, there should be no way that a machine fixed to 100-base-T full
duplex should ever be able to operate properly with a switch set to
auto, and vice-versa. You should always get one end thinking full duplex
and one end thinking half, causing problems. This is where most of the
trouble I've seen here comes from.
> In either case, it is an issue that should always be checked whenever
> someone is having speed issues with a network connection. I've seen too
> many cases of finger pointing that could have been resolved without
> conflict or blame just by getting the switch and the server on the same
> page.
Agreed. Where to look, for those reading and not having been aware, is
generally in the output of netstat -ian. For example, one I just turned
up in the process of writing this e-mail!:
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis
Queue
lo0 8232 127.0.0.0 127.0.0.1 49761 0 49761 0 0 0
eri0 1500 10.34.5.0 10.34.5.108 258367 0 214575 415 897 0
hme0 1500 192.9.160.0 192.9.160.109 105776 0 70512 0 0 0
eri0 is not healthy, and is set to autonegotiate while the switch is set
to 100/Full.
=R
- --
---- _ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer II
|$&| |__| | | |__/ | \| _| |[EMAIL PROTECTED] - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHmQOwmb+gadEcsb4RAqXqAKDQe7Cb964wo1TAG4fF9ONiY+QveACfTVDf
cdCGqBrwVhEDVVOzs/r1fzI=
=YX1Q
-----END PGP SIGNATURE-----
begin:vcard
fn:Ryan Novosielski
n:Novosielski;Ryan
org:UMDNJ;IST/AST
adr;dom:MSB C630;;185 South Orange Avenue;Newark;NJ;07103
email;internet:[EMAIL PROTECTED]
title:Systems Programmer III
tel;work:(973) 972-0922
tel;fax:(973) 972-7412
tel;pager:(866) 20-UMDNJ
x-mozilla-html:FALSE
version:2.1
end:vcard
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
