Linux shaping packet loss

Matlock, Kenneth L MatlockK at
Tue Dec 8 09:18:57 CST 2009

The biggest problem with duplex had to do with 100mb.

Cisco (and a lot of other companies) decided in their infinite wisdom
that at 100mb if auto-negotiation fails, to use half duplex as the
default. So if you have both sides at auto, or both sides hard-set it's
all good. But if one side is hard-set and the other is auto, a lot of
times the auto device will come up 100/Half.

These days at 1Gb+ Full-Duplex seems to be the 'default' for
auto-negotiation failures.

Ken Matlock
Network Analyst
Exempla Healthcare
(303) 467-4671
matlockk at

-----Original Message-----
From: Joe Abley [mailto:jabley at] 
Sent: Tuesday, December 08, 2009 8:14 AM
To: sthaug at
Cc: nanog at
Subject: Re: Linux shaping packet loss

On 2009-12-08, at 15:01, sthaug at wrote:

>> Won't say I'm an expert with TC, but anytime I see packet loss on an 
>> interface I always check the interface itself...10% packet loss is 
>> pretty much what you would get if there was a duplex problem. I
>> try to hard set my interfaces on both the Linux machines and
> Used to set everything hard five years ago. Nowadays auto works just
> fine most of the time.

I find there is a lot of hard-coded wisdom that hard-coded speed duplex
are the way to avoid pain.

The last time I saw anybody do a modern survey of switches, routers and
hosts, however, it seemed like the early interop problems with autoneg
on FE really don't exist today, and on balance there are probably more
duplex problems caused by hard-configured ports that are poorly
maintained in the heat of battle than there are because autoneg is

I've also heard people say that whatever you think about autoneg in Fast
Ethernet, on Gigabit and 10GE interfaces it's pretty much never the
right idea to turn autoneg off.

I am profoundly ignorant of the details of layer-2. It'd be nice to have
more than vague rhetoric to guide me when configuring interfaces. What
reliable guidance exists for this stuff?


More information about the NANOG mailing list