Problem

[matthew.scala]

I recently noticed a problem on my network involving my access-layer switches. When I do a 'show logging' on just about any access-layer switch.. this is the output I get..

Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)

Console logging: disabled

Monitor logging: level debugging, 0 messages logged

Buffer logging: level debugging, 2580 messages logged

File logging: disabled

Trap logging: level informational, 2584 message lines logged

Logging to 131.30.10.251, 2584 message lines logged

Log Buffer (4096 bytes):

Mar 13 22:56:30: %SYS-5-CONFIG_I: Configured from console by snidert on vty2 (131.30.10.39)

Mar 17 14:32:17: %LINK-3-UPDOWN: Interface FastEthernet0/18, changed state to down

Mar 17 14:32:18: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to down

Mar 17 14:32:22: %LINK-3-UPDOWN: Interface FastEthernet0/18, changed state to up

Mar 17 14:32:23: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to up

Mar 17 16:58:04: %LINK-3-UPDOWN: Interface FastEthernet0/15, changed state to down

Mar 17 16:58:05: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/15, changed state to down

Mar 18 15:54:50: %LINK-3-UPDOWN: Interface FastEthernet0/15, changed state to up

Mar 18 15:54:51: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/15, changed state to up

Mar 19 13:40:21: %LINK-3-UPDOWN: Interface FastEthernet0/23, changed state to down

Mar 19 13:40:22: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/23, changed state to down

Mar 19 13:40:26: %LINK-3-UPDOWN: Interface FastEthernet0/23, changed state to up

Mar 19 13:40:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/23, changed state to up

Mar 20 23:11:43: %LINK-3-UPDOWN: Interface FastEthernet0/20, changed state to down

Mar 20 23:11:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/20, changed state to down

Mar 20 23:11:47: %LINK-3-UPDOWN: Interface FastEthernet0/20, changed state to up

Mar 20 23:11:48: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/20, changed state to up

Mar 20 23:12:13: %LINK-3-UPDOWN: Interface FastEthernet0/18, changed state to down

Mar 20 23:12:14: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to down

Mar 20 23:12:18: %LINK-3-UPDOWN: Interface FastEthernet0/18, changed state to up

Mar 20 23:12:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to up

--More--

Etc., etc... and on it goes. This is a 3524-PWR-XL running version 12.0(5.3)WC(1) I'd really appreciate any & all help to resolve this problem. Thanks.

- Matt

[rlotwala]

Hi Matt,

What kind of device is connected to your ports which are showing state up, down and up? It may be printer connected to that port.

Verify your interface with the following command to check for any errors:

sh interface fastethernet 0/18

You'll see the following output

FastEthernet0/18 is down, line protocol is down

Hardware is Fast Ethernet, address is 0006.d771.b34b (bia 0006.d771.b34b)

MTU 1500 bytes, BW 0 Kbit, DLY 0 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive not set

Auto-duplex , Auto Speed , 100BaseTX/FX

ARP type: ARPA, ARP Timeout 04:00:00

Last input never, output 17:22:35, 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 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

5722755 packets input, 2080995023 bytes

Received 3558 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 68 multicast

0 input packets with dribble condition detected

6760649 packets output, 2262337075 bytes, 0 underruns

0 output errors, 0 collisions, 1 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

Look for any CRC error, dropped packets, Interface reset etc. Also make sure that the ports are set to Auto negotiate.

You should not see any CRC errors or packet drop.

Clear your counters and monitor.

I hope this will help you.

Thanks.

Raj

NYC Department of Correction

[matthew.scala]

Devices that are connected to the switchports are user workstations. This problem occurs regardless of whether the port is set to auto-negotiate or hardcoded.

- Matt

[dave.keith]

Within our network these messages indicate that a station has been powered up , powered down , or restarted. I don't think that these messages nessesarily mean there is a problem.

[matthew.scala]

Dave.... I know this. ;) If you check the log.. it shows this for only specific ports.. and it happens constantly (many times within a few seconds).. and this is spanning across all my access-layer switches. One thing I'm figuring could be NIC incompatibility.. but I'm not sure.. any suggestions?

- Matt

[a.manosca]

If this is caused by NIC incompatibility, you should see input errors and CRC errors on the switch ports. Just clear the counters before checking if there are errors or CRCs and verify if they are increasing.

[milan.kulik]

Hi,

try to check following:

"Windows 2000 and Windows ME employ a power management capability that can disable the NIC. When the NIC is disabled for power management, the NIC will drop link to the switch. If there is a concern of link going up/down on NICs using operating systems Windows 2000 or Windows ME, disable the power management feature as a first means of troubleshooting link up/down situations."

See http://www.cisco.com/warp/public/473/46.pdf for details.

Regards,

Milan

[njd]

Check the physical cable length from the switch to the workstation. I've seen similar problems when the distance is too great.

[schlemmer]

If you don't want to get this messages in your logfiles because they're only caused by "client" pc's , than put a

"no logging event link-status"

and

"no snmp trap link-status"

on each interface, which belongs to a client pc. Usually, those interfaces need not to be monitored, but it depends on you. If you say, hey, maybe there's a problem with the client (if it occurs very frequent, but this doesn't seem to be in your case) you'll better leave it on OR you would say it's just a normal power off/power on of the user pc....than you better turn off these messages with the above commands.