Duplex Questions

jscimeca715

Just trying to tie up some loose ends before I take the ICND1 on Friday, and I have a question about duplex and auto-negotiation:

What is the scenario you can get where there is a duplex mismatch and the interface is still in an up and up state?

The reason I'm asking is because if you manually configure a duplex mismatch then, as far as I've seen, a shutdown occurs.

However, the book says that you'll notice increasing collisions and other counters when there is a duplex mismatch. Is this only when one is auto-negotiating with the other?

Any help would be appreciated.

wbosher

Are you configuring a duplex mismatch on real gear or a simulator?

I have noticed that the interface shuts down on Packet Tracer, but on real gear I've noticed that it generally just (severely) slows down the interface due to multiple collisions.

phantasm

wbosher wrote: »

Are you configuring a duplex mismatch on real gear or a simulator?

I have noticed that the interface shuts down on Packet Tracer, but on real gear I've noticed that it generally just (severely) slows down the interface due to multiple collisions.

This has been my experience as well. I get calls all the day from metro-e customers complaining about slow speeds. The first thing I check is the speed and duplex settings after I do a sh int. Chances are, I'll see a crap load of input errors and crc errors coming from the customer side.

miller811

Wikipedia can explain it better than I can

When a device is operating in full duplex while the other one operates in half duplex, the connection works at a very low speed if both devices attempt to send frames at the same time. This is because data can be sent in both directions at the same time in full duplex mode, but only in one direction at a time in half duplex mode. As a result, a full duplex device may transmit data while it is receiving. However, if the other device is working in half duplex, it does not expect to receive data (because it is currently sending); therefore, it senses a collision and attempts to resend the frame it was sending. Depending on timing the half duplex device may sense a late collision, which it will interpret as a hard error rather than a normal consequence of CSMA/CD and will not attempt to resend the frame. On the other hand, the full duplex device does not detect any collision and does not resend the frame, even if the other device has discarded it as corrupted by collision. Still, the full duplex device, not expecting incoming frames to be truncated by collision detection, will report frame check sequence errors. This combination of late collisions reported at the half-duplex end and FCS errors reported by the full duplex end can be used as an indication that a duplex mismatch is present.

This packet loss happens when both devices are transmitting at the same time. This may happen even when the link is used, from the user's perspective, in one direction only. A TCP stream requires all packets sent to be acknowledged by the receiving device. As a result, even if actual data is sent in one direction only, collision may be generated with acknowledgement packets traveling in the other direction

jscimeca715

Excellent guys, it was on a simulator. On the exam I'll look for duplex mismatches when traffic is slow. I appreciate the input.

phantasm

jscimeca715 wrote: »

Excellent guys, it was on a simulator. On the exam I'll look for duplex mismatches when traffic is slow. I appreciate the input.

Remember it for the field as well. I look for speed/duplex mismatches all the time.

Netwurk

Have run across speed/duplex issues a boatload of times at work.

And in my lab, I've slowed down my own home computers a time or two by moving some cabling around and forgetting that I had custom speed and duplex settings on either the NICs or the ports.

Here's some of the common interface commands on the Cisco's...

speed auto
speed 10
speed 100
speed 1000

duplex auto
duplex full
duplex half

I've also seen some models that accept these commands:

full-duplex
half-duplex

Never saw an auto-duplex command, maybe because it's the default?

Not a big deal, since the old commands (like duplex auto) still work.

And you'll see also options for speed 4 and speed 16 with some (usually older) models. I highly doubt you'd ever get tested on it, but those settings are for token ring.

jscimeca715

Netwurk wrote: »

Have run across speed/duplex issues a boatload of times at work.

And in my lab, I've slowed down my own home computers a time or two by moving some cabling around and forgetting that I had custom speed and duplex settings on either the NICs or the ports.

Here's some of the common interface commands on the Cisco's...

speed auto
speed 10
speed 100
speed 1000

duplex auto
duplex full
duplex half

I've also seen some models that accept these commands:

full-duplex
half-duplex

Never saw an auto-duplex command, maybe because it's the default?

Not a big deal, since the old commands (like duplex auto) still work.

And you'll see also options for speed 4 and speed 16 with some (usually older) models. I highly doubt you'd ever get tested on it, but those settings are for token ring.

Thanks Netwurk, and from what I remember you can put no duplex [half/full] and no speed [10/100/1000] which basically sends it back to auto-negotiation right?

Netwurk

jscimeca715 wrote: »

Thanks Netwurk, and from what I remember you can put no duplex [half/full] and no speed [10/100/1000] which basically sends it back to auto-negotiation right?

Verified a couple of things in my lab

Commands to set the interface back to auto-negotiate are

no speed
no duplex

miller811

Netwurk wrote: »

Verified a couple of things in my lab

Commands to set the interface back to auto-negotiate are

no speed
no duplex

also my favorite
default int f0/X
since the default behavior is auto/auto

wbosher

Need to watch out for "duplex auto" set on the switch, it doesn't always seem to work. We had a case at work where a user had his PC set to full duplex but the switch was set to auto, there were truckloads of collisions and errors and everything was running really slow. We hardcoded the switch interface to "duplex full" and the problem went away instantly.

cisco_trooper

Yep. auto-negotiate is a POS but I still use it for access ports. Uplinks, WAN, etc are all hard-coded.

Netwurk

wbosher wrote: »

Need to watch out for "duplex auto" set on the switch, it doesn't always seem to work. We had a case at work where a user had his PC set to full duplex but the switch was set to auto, there were truckloads of collisions and errors and everything was running really slow. We hardcoded the switch interface to "duplex full" and the problem went away instantly.

Always seems to be that if the PC or server's NIC is set manually, the switchport also needs to be set manually. We've had to ratchet a few gig NICs down to 100 to get them to play nice with our access switches (which have 100Mbps ports). And it never seems to work if the switch is set to auto on speed or duplex. The duplex always seems to drop to half (on the switch) if you don't set it up manually.

I think the last time we ran into this was when we replaced our older 6500's with 3750's (using the stackwise cables).