Troubleshooting extremely slow fiber link between 2x2960S switches

[edwardbrauer]

Hi everyone,

Please excuse my very limited knowledge - I'm halfway through my CCNA and have suddenly been tasked with looking after my company's routing and switching, which is on one hand great but also very intimidating.

I recently replaced two faulty Lynksys switches at one of our sites with two Catalyst 2960S devices. The first switch was connected to all our network resources - file servers, internet, exchange etc and also used by the front office to access these resources. The second switch sits a few hundred meters away in the engineering bay and is connected to the first switch via a fibre link. It is for user access to resources only. 

Since migrating to the new switches, users in the engineering bay have complained of incredibly poor speed. Just browsing between directories of our file server takes a good few seconds - it's pretty ridiculous. Meanwhile users on the primary switch - the one hooked up directly to the resources - have no trouble at all.

The only thing I found was that when I initially hooked the switches up, the fibre link between them was running half duplex on both sides. I changed this to full and restarted each interface, but this did nothing.

I've done a sh int gi1/0/50 on the engineering switch's fibre port in an attempt to understand how much traffic is running across this link. As far as I can see, there's practically no traffic running across it at all. But being extremely green on my routing and switching, I could be wrong. 

I'm at my wits end and could really do with some expert advice on this. I realise it could be the simplest of answers and I apologise in advance for wasting anyone's time, but please ... help!

Output from the fibre interface of engineering bay is below:

Switch#sh int gi1/0/50
GigabitEthernet1/0/50 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is 58bf.eaf0.4532 (bia 58bf.eaf0.4532)
  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, link type is auto, media type is 100BaseFX SFP
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:12, output 00:00:01, output hang never
  Last clearing of "show interface" counters 23:55:25
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 141790
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 186000 bits/sec, 35 packets/sec
  5 minute output rate 141000 bits/sec, 35 packets/sec
     5499381 packets input, 2811596261 bytes, 0 no buffer
     Received 239760 broadcasts (87898 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 87898 multicast, 0 pause input
     0 input packets with dribble condition detected
     4706286 packets output, 2653479185 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 PAUSE output
     0 output buffer failures, 0 output buffers swapped out

[Sanjay Shaw]

Could u clear the counter for the int g1/0/50 as this has many output drops which am not too sure and might be historical.Output drops, in my understanding, happens when you try to send more data out an interface than can be received by the equipment at the other end.
Why are you using ur gig port to 100 mbps. Will recommend to change to Gig speed.
Also enable the udld aggressive on both the end // go the fibre testing  //may also u can try changing the SFP.

[edwardbrauer]

Thanks so much for your reply.

I cleared the counters yesterday, so what you're looking at represents a day's worth of traffic. 

I was afraid someone would suggest changing the SFP - I purchased the 100Mbps SFPs myself last week - a poorly informed decision that I was under a lot of pressure to make quickly. Before I tell my boss that I made a mistake and that we need to spend more money I wanted to be sure that changing to 1000mbps SFPs would actually fix the problem, hence posting here. 
I've enabled udld aggressive on both ends. What do you mean by "go the fibre testing"? How would I test the fibre link?
If nothing else works, I'll have to change the SFP, but at present this is a last resort.

Thanks again 

[Sanjay Shaw]

Hi ,

Please find a wonderful Doc of Great LEO to have a testing.

https://supportforums.cisco.com/document/74231/how-use-time-domain-reflectometer-tdr

To answer your sfp will fix the issue, then i must tell u to follow a standard practice for unforseen overhead in ur n/w.

[Leo Laohoo]

Since migrating to the new switches, users in the engineering bay have complained of incredibly poor speed. Just browsing between directories of our file server takes a good few seconds - it's pretty ridiculous. Meanwhile users on the primary switch - the one hooked up directly to the resources - have no trouble at all. 

Full-duplex, 100Mb/s, link type is auto, media type is 100BaseFX SFP

The people at the engineering bay is daisy-chained on a 100 Mbps link.  This may NOT be enough.  Depending on how saturated your main 2960S (connected to the servers) this could be your potential culprit.  

I would also like to see what the "sh interface <PORTS>" of the main switch is like.