3500 XL series Full Duplex/Half Duplex

[Rock2447]

We have a series of Cisco 3524 XL switches in our environment. If we set the workstations/servers attached to them to 100MB Full Duplex the port will for no reason change to half duplex. If we set it to auto it may go half or full depends on the server. Is there something we can do to make everything full duplex or is it of to have half duplex devices. Everything on our network running at half has collisions.

 

[bierhunter]

Sometimes the ports don't autonegotiate very well. When I run into that problem, I manually set the port to what I want it to be.

In the case of the 3524XL

conf t
int fa0/1 (or whichever port)
speed 100
duplex full
end

Also, check to make sure you don't have any cabling problems.

 

[Rock2447]

Should we force Full Duplex to the workstation and the switch?

 

[bierhunter]

I would just force it at the switch first and see what happens. You want to keep your system management as centralized as possible, so changing all the NICS isn't really desirable. Only if necessary.

 

[baddos]

If you need to change the port settings, do it on BOTH the switch and the NIC card. Setting one and not the other could cause problems with auto negotiation on the side that isn't set.

I had problems hard setting the 3524's to 100/full with Intel network cards. I found when using Intel cards, to set both ends to auto.

 

[bierhunter]

The reason I say only change it at the Switch first is because I'm used to dealing with about 20,000 workstations. You don't want to have to send a tech out to make minor changes all the time unless absolutely necessary.

If you change it at the switch and it works, great. If it doesn't, then have someone tweak the workstation's NIC as well. Workstations get moved around where switches usually don't, so you want the workstation to be as dynamic in its configuration as possible. Otherwise, your manpower requirement is going to go up. When configuring your network, you want to keep in mind the ongoing support over time.

The only NICs I've ever had to force a setting on were Jet Direct cards in printers, and those can be done remotely as well.

Intel cards can be a pain in autonegotiation that's true, so we don't use them except for Gig connections. Those are full duplex anyway. Since the 10/100 Intel cards were flakey, we made a policy not to use them. It was cheaper to change brand than to mess with them.

 

[champ007]

hi..

if u set switch port 100full duplex..u have to set on server also the same.one question for u..which operating system do u have..is winnt or unix based..if unix based u have to set both 100 half duplex..because unix server are working only on 100mbps half duplex...pls confirm

 

[Rock2447]

We are going to force Full to both server and switch. We use Intel nics and 3com nics so we will try auto and full on both.

 

[bierhunter]

if unix based u have to set both 100 half duplex..because unix server are working only on 100mbps half duplex

I'm just curious...

What type of system are you running? I've never seen that problem before. We have HP, Sun, and Silicon Graphics Unix boxes all at full duplex.

We do have some older HP Unix system that are stuck at Half, but they're pretty old.

 

[Rock2447]

I need to know if this syntax is correct that was told earlier in a thread

In the case of the 3524XL

conf t
int fa0/1 (or whichever port)
speed 100
duplex full
end

My boss thinks this is wrong?

 

[baddos]

That is the correct commands. One thing you want to do after your configuring, is issue a "clear count". This will reset the counters for the interfaces, and then you can see if there are any current errors coming in.

Then just do a show int fa0/1. It should look something like this:

FastEthernet0/1 is up, line protocol is up
Hardware is Fast Ethernet, address is 0004.6df9.6f41 (bia 0004.6df9.6f41)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 69000 bits/sec, 79 packets/sec
5 minute output rate 181000 bits/sec, 90 packets/sec
227576623 packets input, 1131780267 bytes
Received 17888 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast
0 input packets with dribble condition detected
157393971 packets output, 3172976362 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

Make sure you aren't seeing any collisions or errors.

 

[krr]

This full/half duplex discussion keeps popping up again and again.

Please read

http://www.cisco.com/warp/public/473/3.html

for a detailed explanation on this topic.

And be aware, that even in this forum there is a lot of mis-information spread. Everyone seems to have his/her own opinion about autonegotiation. It isn't always plug-and-play, but trying to fix it and not really knowing what to do, usually makes it worse.

From my experience in network service, 9 out of 10 customers claiming 'performance problems' in their LAN really have problems understanding the full/half duplex issue. The bad thing is, that the problem does not have an obvious effect. Standard ping works like a charm. But the higher the traffic, the more packets you loose. Retransmission takes time and resources, and all you might notice is 'poor performance'.

Cheers *Rob

 

[jlwass]

We have some older Compaq servers with some running NT and some Win2000. With the NT servers, we found setting the switch and the server to 100/full-duplex cleared most of the error issues. The Win2000 servers worked clean whether the switch was set to auto negotiate or 100/full. Cisco has suggested to hard set the port to the speed/duplex the NIC supports.

Jeff

 

[CHM1]

I think autonegotiation has been created to simplify management or administration of the network.
Especially if you have a large network and many changes it's not a good thing to fix problems in configuring anything other than "autonegotiation".
In the long time it's cheaper to change the NIC....

For errors see also

http://www.cisco.com/en/US/tech/tk389/tk214/technologies_tech_note09186a008009446d.shtml

or search Cisco's site with "troubleshooting ethernet collisions"