Network slow at times

[rickyt00]

I am having a strange problem. A couple of my users, are complaining of slow network. I checked the switches that they are on but there aren't hardly any errors or collisions. I checked for viruses,.etc.. on the machine but nothing. The one thing I did notice is there seemed to be a lot of broadcasts, but I checked other 2924's and but they all seemed to be about the same. I posted info from on of my 2924's below. Any ideas, thanks in advance.

FastEthernet0/23 is up, line protocol is up

Hardware is Fast Ethernet, address is 0006.28d5.a297 (bia 0006.28d5.a297)

Description: To Reis 2/8

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, 100BaseFX

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

Last input 00:00:01, output 00:00:01, output hang never

Last clearing of "show interface" counters 1d01h

Queueing strategy: fifo

Output queue 0/40, 0 drops; input queue 0/75, 0 drops

5 minute input rate 60000 bits/sec, 88 packets/sec

5 minute output rate 16000 bits/sec, 20 packets/sec

4301815 packets input, 545035569 bytes

Received 3324142 broadcasts, 0 runts, 8 giants, 0 throttles

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

0 watchdog, 353521 multicast

0 input packets with dribble condition detected

1053475 packets output, 151133605 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

[b.eman]

That is defiantly a lot of broadcasts in 1 day. How many nodes are on that particular segment? If there is less than 100 I would find out where those broadcasts are coming from with an analyzer. May not be your problem considering there is no errors but its a start.

[konigl]

I second the recommendation to use an analyzer to pinpoint the source(s) of the broadcasts. Or, if you have a Cisco Layer 3 device (router or L3 switch) that will let you do access control lists, you could configure some ACLs that permit the traffic but log entries that use TCP, UDP, or ICMP in ways that are characteristic of some of the worms that are out there affecting Microsoft-based networks (Nachi, Blaster).

I had a customer that had a Nachi problem. Just a couple of infected computers were pinging all sorts of IP addresses on and off-subnet, scanning networks for other potential hosts to infect. Brought the network to a standstill. Symptoms were lots of pings, to sequential IP addresses, lots of ARPs not resolving to MAC addresses on the local subnets.

If you can identify the machines causing the traffic, you can run utilities to clean these particular infections. It can be on systems you wouldn't suspect: for examples, copier/printers with a Windows operating system on the attached PC for preprocessing/buffering.

[rickyt00]

Thanks for your help. I am right now using an ACL to block all pings, tftp, anything on ports 135, 137, 138, 139, 445, 593, 707. Welchia/Nachi was supposed to quit on 1/1/2004. So I thought my problems were over with excessive broadcasts. I will setup some logs in my router to see it that will pinpoint the machines it is coming from. Thanks for your help again.

[Rodney-roberts]

one other thing you can do is enable route-cache on your L3 interfaces by issuing the command ip route-cache flow then let it set for a while and check for infected host by doign a show ip cache flow | include 0000 0800