Server plugged into wrong vlan

[jclj]

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)

[Reza Sharifi]

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

[jclj]

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.

[Rick Morris · Accepted solution]

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

[jclj]

No errors. I'm thinking this was due to other circumstances. Thanks for your time and explanations!

[Rick Morris]

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.

http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/12.1_22ea/SCG/swtrafc.html

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.

[jclj]

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.