[c-nsp] full duplex mismatch speed - dynamips

[Gert Doering]

Hi,

On Fri, Aug 20, 2010 at 07:33:14AM +0100, Heath Jones wrote:
> I'm really curious as to why there are many people here saying forcing ports
> is a bad thing though. I was pretty surprised to be reading that actually,
> its good to have another perspective on the idea.

If you force one end, and the other end is set to auto, what usually happens
is that the "auto" end will not see autoneg happening - and has to assume
"I'm connected to a *Hub*, so I must do half-duplex now".

So now you have one side full-duplex, and the other side half-duplex, which
implies "collision detection and avoidance".

Now, the half-duplex side sends out a packet.  Everything fine.  The 
full-duplex side also wants to send out a packet, some us later - and it
will just go ahead and do it, since it does not have to wait for the 
incoming packet to be finished (full-duplex!).

Now, on the half-duplex end, the device notices "oh, something comes in
while I am sending a packet, so this MUST BE A COLLISION" - and drops(!)
both the outgoing and incoming packet.

Boom, you have packet loss.  And the worst thing about this is that the
packet loss is fairly hard to diagnose - if the link is not carrying
background traffic, diagnosing with a single "ping" stream will always
have "packet goes out, reply comes back.  new packet goes out, reply 
comes back", but there will never be two packets on the link at the 
same time -> no collision.

So you assume "everything fine", put the link into production use, and
your customers complain about "internet is slow".


> I've seen countless issues where inter switch links, inter router links and
> also links between servers and switches have cause so many issues. On almost
> all of these occasions, forcing will solve the problem.

Well, of course someone will still stick to the old lore... :-)

> The link is actually going down while the renegotiation happens. This causes
> a L2 topology change, so frames will be dropped. In a service provider
> environment, there will be a L3 topology change - IGP does its thing and
> this may take some time (especially on a heavily loaded router). The end
> result is customers start calling wondering where their traffic went.

Huh?  There is no "renegotiation" going on in nway autoneg.

> It sounds like this is a matter of opinion and the opinion depends on the
> environment in which it is being applied, no ??

Well.  "Practical experience" tends to form opinion, yes.


> I'll be honest here, I've never truely understood the cause of speed duplex
> mismatches. 

See above.  People blindly forcing one side and not ensuring that the
other side is also forced (possibly because that side is configured by
a different group, or whatever).  Or one side of the link getting exchanged
years later, and the new device defaulting to autoneg, etc.

> Noise would be the obvious one, but does noise actually play a
> big part on relatively short cat5 links? Dodgy connectors? Problems with the
> PLL decoder getting out of sync (noise again?)? Faulty clock?? Someone
> jumping on the cable??

People making mistakes is the most common reason, by FAR.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20100820/594eb0f5/attachment.bin>