11-10-2012 12:44 PM - edited 03-07-2019 09:58 AM
Hi, I have all my switches on vlan 1 in our environment. Our production environment is in a different vlan. Last night my boss plugged in a file server into vlan 1 and I got a call later that we had network slowness. I since have logged into the switch and disabled the port.
Now, we had a few things going on last night so I am trying to see if this was the real cause of the slowness. Is it possible if the server plugged into vlan 1 could be sending our arp requests and hitting all my switches causing the network to be slow?
Thanks
(I have been doing the for roughly 4 months and have needed to learn a lot in a short time. Any help would be appreciated. Thanks)
Solved! Go to Solution.
11-13-2012 07:22 AM
Does the interface show any errors?
hscdow01-cr-02#sh int GigabitEthernet2/9/36
GigabitEthernet2/9/36 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 0026.0ba8.ad73 (bia 0026.0ba8.ad73)
Description: hscdow01-lb-02 port 1.2
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is 10/100/1000BaseT
input flow-control is off, output flow-control is off
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 40000 bits/sec, 64 packets/sec
5 minute output rate 139000 bits/sec, 47 packets/sec
1789685498 packets input, 140917712312 bytes, 0 no buffer
Received 1530460 broadcasts (1192261 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
1223164801 packets output, 516073843720 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
11-10-2012 02:16 PM
Hi,
Plugging a server to the switch in vlan 1 should not cause slowness, unless something is wrong with the NIC.
You can also test it by enabling the port and see if the slowness comes back.
HTH
11-12-2012 08:07 AM
Well, the port was going up and down. Do to this I'm wondering if the nic may be bad. If I enable the port it starts to "flap" again.
11-13-2012 07:22 AM
Does the interface show any errors?
hscdow01-cr-02#sh int GigabitEthernet2/9/36
GigabitEthernet2/9/36 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 0026.0ba8.ad73 (bia 0026.0ba8.ad73)
Description: hscdow01-lb-02 port 1.2
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is 10/100/1000BaseT
input flow-control is off, output flow-control is off
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 40000 bits/sec, 64 packets/sec
5 minute output rate 139000 bits/sec, 47 packets/sec
1789685498 packets input, 140917712312 bytes, 0 no buffer
Received 1530460 broadcasts (1192261 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
1223164801 packets output, 516073843720 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
11-13-2012 08:15 AM
No errors. I'm thinking this was due to other circumstances. Thanks for your time and explanations!
11-13-2012 08:23 AM
I would agree with you, Chris.
The motto I learned early on, "If there is a problem, and it is on the network, it is a network problem!"
It becomes the network team responsibility to prove to the "other" groups where the problem is at. Another thing to check during the issue is the CPU. It is possible that the new device is doing something causing the issue, one command to add to the interface:
storm-control broadcast level <%>
storm-control action
%= % of total bandwidth consumed. I.E. .5% means on a 1000Mb connection if the threshold meets 50Mb to do some action, could be to just send it to a syslog server or monitoring server via trap, or you could shut the interface down.
There is also unicast and multicast traffic too you can set.
One thing to check in the CPU is what process is being hit.
sho proc cpu sorted
hscdow01-cr-02#sh proc cpu sort
CPU utilization for five seconds: 93%/13%; one minute: 41%; five minutes: 27%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
555 22146729321197899044 1848 55.19% 14.38% 3.60% 0 SNMP ENGINE
11 12245548002804294845 0 4.63% 3.02% 2.60% 0 ARP Input
311 13098172601711867043 765 4.63% 2.66% 2.38% 0 IP Input
562 15587233962950221669 0 4.07% 2.14% 1.73% 0 IGMP Input
This will help identify the issue from the CPU perspective, which will cause slowness too.
11-13-2012 08:28 AM
It's funny you say this as I was just checking the CPU utilization during that time in our Solarwinds NPM. Doesn't show anything out of the ordinary, but this is good information. Thanks for the tip! I'm not quite familiar with the command line statistics as I would like to be...yet. Solarwinds seems to do a good job, but I want to be able to specifically show these commands in the switch/router as well.
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