Re: Throughput Issue - Packet Loss
- From: fugettaboutit <no@xxxxxxx>
- Date: Mon, 24 Nov 2008 20:33:35 GMT
This is not accurate for two reasons:
First, my comment is that you do not have to have both sides of the link set to auto/auto in every circumstance. Yes, speed and duplex must match in Ethernet, but if you're relying on auto-negotiation, I stand by my previous statement. As I've stated, I've ran into issues where auto on both ends of the link WOULD NOT WORK - late collisions, CRC/framing errors resulted because of duplex mismatches. Either hard coding both ends or even letting one side run auto and the other fixed have actually worked. I've seen this odd behavior with different Ethernet chipsets over the years. If you don't believe me, I have an inter-city metro Ethernet circuit I can demonstrate this very scenario - CE switch (auto) -> MPLS PE (100/FDX fixed).
Second, there is no hard standard for Ethernet 10/100 Mbps auto-negotiation. Much of the spec has been left for vendor interpretation. That's why there are often issues when we talk 10/100 Mbps auto-negotiation. GiGE (a fiber-channel PHY definition) is another animal not included in this discussion.
However, there are two exceptions to my first point that I can think of. One is when it comes to EtherChannel, and the second is the port role in RSTP. My whole point is that you cannot make a blanket statement where generic 10/100 Mbps interconnectivity is involved. You can and sometimes will run into oddities that don't "match spec". Speed/duplex must match, but saying that auto/auto (both sides of the link) is required is not always the case. The irony is that I've seen this with Cisco switch to Cisco router interconnects, and not just with different vendor equipment connection scenarios.
On 24 Nov, 18:20, "Thrill5" <nos...@xxxxxxxxxxxxx> wrote:.If one side is set to auto-negotiate and the other is set to 100/full you
will have a duplex mismatch. The side that is set to auto will attempt to
negotiate duplex, the other side which is hard-coded will not participate.
The auto side will then set the interface to half duplex since the other
side did not respond. You now have a duplex mismatch because one side is
configured for full duplex, and the auto side will fall-back to half. This
is how the standard is written. There are devices that will not negotiate
properly when both sides are set to auto, but this is very rare. The only
way to fix this, is to manually configure duplex and speed on both sides.
In a nutshell, both ends must be configured the same, both auto/auto, both
100/full, or both 100/half. No matter how they are set, you should always
verify that both ends are set correctly.
I agree with Thrill5's comments.
One additional thing is that it is always possible
to determine if you have a duplex missmatch that
is affecting your traffic from the interface counters.
In the event of a missmatch -
The HD side will record Late collisions
The FD side will record CRC errors and or Align errors.
Align errors are often called Frame errors.
If these are not present (and you said there were
no interface errors) then you do not have a missmatch
which is affecting your traffic. It would still be possible
to have a missmatch but if there are no outside of
window collisions then the counters would not
increment and you would not be losing packets
due to this cause.
In the UK most carriers seem to simply
*love* hard set interfaces. BT and Colt
always set their NTE the speed and to FD.
- Re: Throughput Issue - Packet Loss
- From: Thrill5
- Re: Throughput Issue - Packet Loss
- Prev by Date: Re: Throughput Issue - Packet Loss
- Next by Date: Re: can't open port 25, is there anything obvious in this acl?
- Previous by thread: Re: Throughput Issue - Packet Loss
- Next by thread: Re: Throughput Issue - Packet Loss