Issue with Powerconnect 3448P

This may happen if you have a duplex mismatch on your port configuration.  Make sure you setup the port to do "auto-negotiation" on both end of the link.  If you mistakenly setup fixed config on one end and auto-negotiate on the other or mismatch the duplex you will get a situation where the port will work for awhile until excessive collision cause the port to be shutdown.  Check the configuration and status of the ports on both end of the link.

I'm assuming your IP phone has a built in switch.  Make sure you correctly setup that switch configuration so that the ethernet port configuration on the phone matches what's on the 3448.

Can you add some more info to this?
I have about one host each day that becomes inaccessible in this way. I have noticed that the switch shows they are set for full duplex and yet the status shows half duplex on each of these problem children. One time I enabled flow control on one of these ports in the problem state and it locked up the whole switch (whole building).
Is there a way to get that one port reset without moving to another port (remote repair)? These are 3com 3C905Btx NICs and the switch is showing a lot of "late collisions" (for this latest instance anyway).


We have made it a policy (from past experience) to turn off auto-negotiate everywhere possible for faster throughput. I admit this was in the days of 10Mbit/sec LAN links. Should we now consider auto-negotiate a safe default?

The problem with duplex mismatch occurs quite easily if you do not correctly configure the ports on both end of the link.  Meaning that you must make sure that the configuration of the port on the switch matches the configuration of the NIC on the workstation to which this port is connected.

The best way is to configure the port on the switch and the NIC on the PC to do "auto-negotiation" so that they automatically pick the correct speed & duplex when they link up.  If you do configure one of the end to be "fixed" then you must make sure you configure the other end to also be "fixed" to the SAME speed & duplex.  The worse thing you can do is to configure one end to be "auto-negotiate" and the other end to be "fixed".  If one end is auto and the other is fixed, you are almost guaranteed to get duplex mismatch!

You should take a look at your configuration on both the switch and the NIC on the problem hosts and make sure the "speed" and "duplex" either matches fully or that the port and NIC are configured to "auto-negotiation".

Cuong.

Once the port is "dead", I think you need to force re-negotiation.  You might try "shutdown" and restart the port - look here:

<ADMIN NOTE: Broken link has been removed from this post by Dell>.

Let me know if this works for you.

Cuong.

I have had the same happening to me for a week now, and thanks to this thread I figured out what's going on. My only question is, these ports that 'died', are now useless. Is there any way to reset this ports, without requiring a switch reboot? Thanks!

Our switch has been behaving better as well, but we have never found a fix short of a switch restart. That's distasteful.

I would like to hear of a better way than that.

I would also like to know the best way to tell the switch that one host will now be using another port. Sometimes I just want one user to go plug in at the conference room and it will not work or it will work but when they are done they cannot go back to their cube and plug into the old one. (I have not searched this forum for that issue though.)

I already tried the shutdown trick without any results. I ran a sniffer after doing this, and I am seeing no traffic at all. I am really hoping I don't have to do a reboot.

On your question regarding host moving.  I don't understand the issue?  If you move a host from one switch to another, which I do all the time, once the new host connected to another switch and send a packet such as ARP update then the new switch in the network will be updated with the new location of the host.  The old switch where the host used to be connected would age out the host MAC (after link is lost on the port to which the host was connected) but once the routing and bridging tables update then packets destined for the new host will be forwarded to the port on which that host is now connected.  When you move it back the same steps will occur.  The only delay that I can think of would be the delay resulting from STP when the host first connect (you can overcome this by enabling "fast-link" on all the access ports) and the switch/route tables update, which is normal networking process which may not be instantaneous but should work with no problem.

Somethings that could cause this not to work might be if you have security features which lock a MAC to a port or if you configured VLANs that put the new host on a different VLAN depending on where its connected (port based VLAN).  Also if you setup your network such that when the host connect to a different switch or router it ends up on a different subnet and you configure the host with static IP which make it no longer routable in its new location.  There are other ways for it not to work but each of those ways result from some configuration or network engineering issue not a switch function issue.

There are so many things that could cause you not to be able to move your host from switch to switch and to figure out what you need to review how your entire network is setup and consider what happens when you move the host and how the switches and routers in your network need to be updated so that you can move the host from place to place.

Cuong.