When the device connected on one port stops communicating and it starts talking and connecting after it was moved to another port the switch is usually blamed since the device started to work on another port. However, when you disconnect that device/host it is equivalent to bouncing the port. Have you tried bouncing the original port? If you put it back in original port it would probably work. You stated that the port is transmitting but not receiving, switch usually does not control the RX end. It can alos be due to asic issue, have you checked the asic register's errcounters? I can send you a command to check those but I need to know what kind of line card. Then finally, as last resort to find true root cuase is to sniff the port, it's simple to sniff it by simply pinging from a device in the same subnet as that device, you should see confirm whether the switch is sending the packet and if the device is actually responding. If the switch is sending and the device is not responding, it would be hard to argue that it's a switch issue.

Hope that helps in the future.

OK guys (and girls) here is some more info

The line card is WS-X6416-GBIC Switch runs CatOS.

I Plugged in my laptop to that port and sniffed the traffic. My laptop was able to receive CDP info from the switch.

I also run show cam dynamic 9/13 and the MAC was not in the table which means that my notebook cannot send information to the switch.

I checked counters on the port ( show counters 9/13 and can see rxTotalDrops = 44000

Other ports on the line card seem to be fine.

Please send me some other commands that could help me in finding root cause of the problem.

I am not sure if this is a problem with the port alone or a whole card, or a software.

Also the Hw version of that line card is 1.2

Thanks a lot for your help

show asicreg 9/13 pinnacle errcounters - this gets reset on read. Obviously the port have to be connected for this command to give you meaningful output.

show mac 9/13 will give you the port tx/rx counters.

Check to see if dynamic cam entries are being created for any traffic entering the port you are trouble shooting. Make sure that the cam entry is associated with the correct vlan.

sho cam dynamic 9/13

Check for any port related error messages in the log via “show logging buff 1023”.

Make sure that the port in question is forwarding for spanning tree on the correct vlan. Make sure that portfast is enabled or disabled where appropriate.

show spantree 9/13

after i reset the line card. the port started to work.