03-25-2003 07:23 AM - edited 03-02-2019 06:08 AM
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
03-25-2003 07:48 AM
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
03-25-2003 08:04 AM
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
03-26-2003 08:10 AM
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.
03-26-2003 09:08 AM
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
03-26-2003 10:25 PM
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.
03-28-2003 01:21 AM
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
03-27-2003 01:17 AM
Check the physical cable length from the switch to the workstation. I've seen similar problems when the distance is too great.
03-28-2003 01:07 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide