Re: Network works one way only

From: Dr. Oliver Muth (Dr.O.Muth_at_gmx.de)
Date: 05/13/04 

Date: Thu, 13 May 2004 09:30:10 +0200

On Wed, 12 May 2004 19:36:05 +0000, Tauno Voipio wrote:

Hi Tauno,

thanks for your good explanation (that even I understood ;-) ).
But there is still a few things that I don't get yet:

> To get *any* advantage of full duplex, the whole path
> between the peers must be full duplex, a single hub
> on the way spoils it.
There is only a cable between the boxes. (Actually two cables and a
plain connector, since my crossover cable is not long enough.)
So, there shouldn't be anything impeding full duplex negotiation.

> The full duplex setting only prevents the interface
> card from listening for traffic on the line before
> transmitting, half duplex postpones transmitting till
> the line is idle. If there is a full/half mismatch
> on any segment, the full duplex end will misbehave
> sending on top of other traffic, which creates plenty
> of back-offs and retransmits.
Why does this selectively filter out fragmented packets?
Ethereal shows that the first fragment goes through,
but all following fragments of the same packet get lost.

And even more confusing to me:
Why does it help to set the interface of the server to half
duplex (with mii-tool) while leaving the interface of the laptop
on full duplex? I can manually set the interface of the laptop to whatever
I want to - it does not matter! Only if I set the server interface to half
duplex, the fragments come through.

BTW: Since it obviously does not have anything at all to to with the
nfs-server, I changed the test now: I use ping -s [packetsize > mtu]
instead of writing to and reading from an nfs-drive.
Of course I checked that the results are the same.

> There are hubs/switches which mis-negotiate the setting.
>
> IMHO, full duplex is not worth the sweat, unless
> the link belongs to a very busy backbone.
OK, but that forces me to always put those interfaces manually
into half duplex mode, since they auto-negotiate full duplex each time.
Isn't there a more elegant fix?

Or is one of the network cards or its driver broken?
How to find out which?

Best regards

Oliver

Relevant Pages

  • Re: Problem Daisy-Chaining 2950 Using Copper Giga
    ... > Did you check the speed and duplex settings of the running ports. ... >> switch to connect to two other 2950's using switchport mode trunk for VLAN ... >> interface FastEthernet0/1 ...
    (comp.dcom.sys.cisco)
  • Re: Problem Daisy-Chaining 2950 Using Copper Giga
    ... My first thing to check would be to see whether one port came up in duplex and the other in half duplex or so. ... switch to connect to two other 2950's using switchport mode trunk for VLAN ... extremely high number of input errors on the VLAN1 interface of the ... no spanning-tree optimize bpdu transmission ...
    (comp.dcom.sys.cisco)
  • Re: two NICs and speed issues
    ... > So if you disconnect the modem the transfers are fast on the ... > will give you a listing of each interface. ... > connections you want to have full duplex set. ... > between the NIC and the switch you will see the error count increase ...
    (Fedora)
  • Re: Dropped packets via ISR
    ... I also used ping plotter... ... Tried changing from full duplex to half duplex to auto and that did ... "1) Interface MTU at 1500 is fine. ...
    (comp.dcom.sys.cisco)
  • [UPDATE] v100 and flapping dmfe0 ethernet interface
    ... I have had a couple of replies which discussed duplex issues. ... the interface was flapping every 5 seconds. ... 100 Mbps Full-Duplex ...
    (SunManagers)