Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Slow performing 2950

Status
Not open for further replies.
Mar 30, 2003
172
NZ
I've got a Cisco 2950 and moving data between PC's plugged into it is slow!! It may peak at 10Mbs coming from a PC (Watching with AnalogX NSLive and MRTG) but on a direct file copy between two windows boxes its more like 1Mbs. Everything is hard set 100 full with static IP's

Could someone look at the config and see if they have any suggestions?

Config below; I cut out the interfaces to save space

Verison: C2950 Software (C2950-I6Q4L2-M), Version 12.1(12c)

!
version 12.1
no service single-slot-reload-enable
no service pad
service timestamps debug uptime
service timestamps log datetime
no service password-encryption
service sequence-numbers
!
hostname ciscoswitch
!
enable password password
!
ip subnet-zero
!
spanning-tree extend system-id
!
!
interface FastEthernet0/1
description Terry Test
no ip address
duplex full
speed 100
!
interface GigabitEthernet0/1
description
switchport access vlan 12
no ip address
duplex full
speed 1000
!
interface GigabitEthernet0/2
description UPLINK to S4
switchport mode trunk
no ip address
speed 1000
!
interface Vlan1
ip address 192.168.0.12 255.255.255.0
no ip route-cache
!
ip default-gateway 192.168.0.1
ip http server
!
snmp-server engineID local 800000090300000C30832D41
snmp-server community sntmpplace RO
snmp-server location Rack
snmp-server contact IT
snmp-server chassis-id ciscoswitch
!
line con 0
exec-timeout 0 0
line vty 0 4
password password
login
line vty 5 15
password password
login
!
end
 
Make sure that your PC's are set to 100/full and not auto
also replace patch cables

then also look at the port statitics, are there crc error, collissions, etc...
 
Tired different patch lead
All hard set to 100 full

ERrors looked passable to me; here is a show in on one


FastEthernet0/3 is up, line protocol is up
Hardware is Fast Ethernet, address is 000c.3083.2d43 (bia 000c.3083.2d43)
Description: bob
MTU 1500 bytes, BW 100000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
input flow-control is off, output flow-control is off
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/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 745000 bits/sec, 170 packets/sec
5 minute output rate 491000 bits/sec, 175 packets/sec
2166636861 packets input, 1752276553 bytes, 0 no buffer
Received 1383009 broadcasts, 0 runts, 0 giants, 0 throttles
181 input errors, 1 CRC, 180 frame, 0 overrun, 0 ignored
0 watchdog, 4339 multicast, 0 pause input
0 input packets with dribble condition detected
2298213219 packets output, 3530204639 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
 
I had the same problem when we 1st went to 2950's. Turned out to be the NIC drivers on the PC's needed updating. Best bet is to remove the NIC from Device Manager and reload with latest drivers. (Ours were 3Com)

If you are in a very "noisey" (electical noise) enviroment, you may have to turn down to 10. (or run shielded cable, had to do that here with lines that ran anywhere near our alarm lines)

R.Lee
 
Hi

Did you solve the problem, because I have very similar slowdown problem. I'm also using trunk (dot1q) and it's between 2950 and 2900XL. 25Mb file takes about 30 seconds to transfer between 2 computers.

Best regards,
Antti
 
which interfaces were you transferring between , one interface is in vlan 12 , if one of your interfaces was in vlan 12 then this would have had to been routed by a router and then sent back down to the switch which could slow it down also depending on the thruput of the router .
 
I would also check all links above this , your pc on vlan 12 would have had to traverse the trunk to S4 , I don't know if S4 is doing the routing or if it takes another hop from there to a router but to go from vlan 12 to vlan 1 it would have to be routed so check all links in this path to and from the router back to your originating switch.
 
Just between fa 0/1 and fa 0/2. I haven't put the full config for that switch because the rest of the ports were all the same except for some differences in descriptions, vlan memberships and port speeds etc.

We never really solved this one. We reduced the problem by updating firmware and drivers on all of our IBm servers; it still isn't great, but its not bad.
 
I actually solved this problem yesterday, simple IOS upgrade. I had version 12.1(13)EA1 in my 2950 switch which propably have some strange speed problem if trunking is used. I upgraded it to 12.1(22)EA1 and all speeded up immediately after reboot.

Hope this helps you also,
-Antti
 
Just for your info, speed was very slow between 2 hosts connected to switch ports and also to hosts behind the trunk link. So the whole switch was very slow after trunking was turned on.

-Antti
 
>
> Make sure that your PC's are set to 100/full and not auto
>

That is *really* bad advice. With newer switches like the 2950 you should always leave the switchport at AUTO and configure your connected devices to use AUTO. Only manually configure settings if you have a device that can't autonegotiate, which should be a rare occurrence.

The old "auto is bad" adage is completely, horribly wrong anymore. Autonegotiation everywhere will result in far less troubleshooting for you in the long run. Never, ever, manually configure 100/Full unless you absolutely have to. If you have to manually configure your settings, the safest setting is 100/half.

If anyone wants me to explain why, just let me know. It's early and I don't feel like typing more than I need to! :)

Regards,
John
 
Now, I will admit I am a bit old school and I haven't looked into this particular issue in recent years, but it has always been my understanding that network devices do great for working out speed (10 / 100) but when using copper media it is not uncommon for the duplex to be incorrectly mismatched.

Here is an extract from a webpage I found on a quick google search; they may well be trying to justify their product, but I have read similar before.

Here's how auto-negotiation works. Whenever two copper 10/100 ports talk to one another there is a negotiation process. Each port broadcasts its capabilities. It may say it can do 10 Mbps or 100 Mbps or both; or that it can handle full-duplex or only half-duplex, or both. A typical switch can do either 10 or 100, either full or half. If both have similar capabilities, they resolve to the highest performing common denominator (in this case 100 Mbps full-duplex). However, if a 10/100 switch is being connected to a dual-speed hub, the switch will come up and say it can do 10 or 100, full or half-duplex; the hub will say it can do 10 or 100, but can only do half-duplex. The result will be a 100 Mbps half-duplex link.

Lastly, consider a switch talking to an old, legacy NIC (network interface card). It may be a 100BASE-T NIC which does not have auto-negotiation. It is fixed at 100 Mbps. Again, the switch tries to establish a contact. But the NIC ignores the requests, since it has no idea what the switch is requesting. The NIC does not respond in auto-negotiation language. The answer to the conundrum is "parallel detection." When it does not get an auto-negotiation response, but rather discovers a legacy device, it has to respond in kind.

Parallel detection allows the intelligent device to detect the speed (in this case 100 Mbps), but has to take the safer road and set up a link based on the lowest common denominator: half-duplex.

 
You may still run into problems with old (4+ years) NICs or with bad NIC drivers, etc., but with newer Fast Ethernet equipment (and I'm talking _switches_, not hubs) you should stick to setting both sides of the link to auto.

The advice you got on the page was valid a few years ago but it's less relevant now, especially when you're talking about a Cisco Catalyst 2950 and a modern PC, not a 100 Mbps hub.

Regards,
John
 
Hi all,

The Problem ist that you Softare is buggy. You have to upgrade it to a newer one.

Greetings
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top