- Network performance issues with 3500XL
- Posted by Jon Fanti on February 9th, 2006
Hi guys,
This one has been puzzling me for some time now, and I was hoping for a
bit of advice from the experts!
Currently we have 4 Cisco 3500XL switches, connected like so:
office1.switch.net----<GBIC Fiber>----office2.core.switch.net----<GBIC
Fiber>----office2.switch1.net----<GBIC Fiber>----office2.switch2.net
Not the best representation of how our switches are connected, but the
best I could manage 
Okay, now onto our problem:
We have all servers connected to the "core" switch, and then users are
split across the other three switches. We don't have any VLAN in place.
here is a brief run down of our configs (I've only copied one config
into this post, since they are mostly identical - except for management
IP/hostname).
---
Current configuration:
!
version 12.0
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname lisson-sw1.unique.lan.int
!
enable secret 5 ***.
!
!
!
!
!
!
ip subnet-zero
!
!
!
interface FastEthernet0/1
!
interface FastEthernet0/2
!
interface FastEthernet0/3
!
interface FastEthernet0/4
!
interface FastEthernet0/5
!
interface FastEthernet0/6
!
interface FastEthernet0/7
<snipped>
interface VLAN1
ip address 172.16.1.245 255.255.255.0
no ip directed-broadcast
no ip route-cache
!
ip default-gateway 172.16.1.10
snmp-server engineID local 00000009020000046DFEA140
snmp-server community private RW
snmp-server community public RO
snmp-server community Un1qu3 RO 27
snmp-server location Lisson Street, London, UK
snmp-server contact help@unique.com
!
line con 0
transport input none
stopbits 1
line vty 0 4
password ***
login
line vty 5 15
password ***
login
!
end
---
All our users are on Windows XP SP2 clients with the Windows firewall
disabled. But all users are experiencing packet loss to servers -
typically 8%-20% loss. However, from servers (Linux based) to the same
desktop PC I will get no packet loss at all, windows based servers (2003
SP1), and NetWare based servers (OES/NW6.5) result in the same packet
loss as desktop PC's.
Our switch logs show (ignore the dates, switches have not been
configured for NTP):
---
Log Buffer (4096 bytes):
6:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 325 addrs per min
*May 17 17:47:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 497 addrs
per min
*May 17 17:48:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 146 addrs
per min
*May 17 17:49:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 98 addrs
per min
*May 17 17:50:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 297 addrs
per min
*May 17 17:51:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 482 addrs
per min
*May 17 17:52:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 479 addrs
per min
*May 17 17:53:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 469 addrs
per min
*May 17 17:54:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 243 addrs
per min
*May 17 17:55:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 140 addrs
per min
*May 17 17:56:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 55 addrs
per min
*May 17 17:57:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 94 addrs
per min
*May 17 17:58:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 56 addrs
per min
*May 17 17:59:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 53 addrs
per min
*May 17 18:00:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 27 addrs
per min
*May 17 18:01:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 28 addrs
per min
*May 17 18:02:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 41 addrs
per min
*May 17 18:03:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 29 addrs
per min
*May 17 18:04:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 31 addrs
per min
*May 17 18:05:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 30 addrs
per min
*May 17 18:06:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 46 addrs
per min
*May 17 18:07:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 62 addrs
per min
*May 17 18:08:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 36 addrs
per min
*May 17 18:09:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 23 addrs
per min
*May 17 18:10:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 32 addrs
per min
*May 17 18:11:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 19 addrs
per min
*May 17 18:12:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 38 addrs
per min
*May 17 18:13:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 62 addrs
per min
*May 17 18:14:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 29 addrs
per min
*May 17 18:15:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 67 addrs
per min
*May 17 18:16:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 47 addrs
per min
*May 17 18:17:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 271 addrs
per min
*May 17 18:18:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 146 addrs
per min
*May 17 18:19:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 179 addrs
per min
*May 17 18:20:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 186 addrs
per min
*May 17 18:21:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 401 addrs
per min
*May 17 18:22:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 288 addrs
per min
*May 17 18:23:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 380 addrs
per min
*May 17 18:24:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 304 addrs
per min
*May 17 18:25:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 183 addrs
per min
*May 17 18:26:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 144 addrs
per min
*May 17 18:27:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 136 addrs
per min
*May 17 18:28:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 100 addrs
per min
*May 17 18:29:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 112 addrs
per min
*May 17 18:30:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 115 addrs
per min
*May 17 18:31:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 169 addrs
per min
*May 17 18:32:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 293 addrs
per min
*May 17 18:33:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 619 addrs
per min
*May 17 18:34:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 451 addrs
per min
*May 17 18:35:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 200 addrs
per min
*May 17 18:36:45: %RTD-1-ADDR_FLAP: FastEthernet0/1 relearning 134 addrs
per min
---
Any suggestions would be useful, I'm banging my head against the wall a
bit here!
Thanks,
Jon!
- Posted by Pat D on February 9th, 2006
Looks like a spanning tree loop, if it is then you'll probably have
small outages on the network. If so you should remove the redundant
links from your network. Look at how you've configured the links
between the switches. Here's a link from CCO
http://www.cisco.com/warp/public/473/131.html
Check the spanning tree parameters also and find out where the root
bridge is too.
- Posted by Horst Wagner on February 9th, 2006
Hi John,
are you sure your cabling and config is like you stated in your mail?
Your problem looks like a bridging loop leading the big amounts of broadcast storms and frames switched to the wrong ports. But therefore you must have cabling redundancy and a misconfigured spanning tree. For example if you configure spanning-tree uplinkfast on all switches or something like that.
Do the LED's on the switches flicker like hell even if there's nobody working?
Try investigating in that!!
good lick Horst
Horst Wagner
(CCIE# 7975, CCSI# 20806}
Konkret Netzprojekte GmbH Friedrich Mohr Str. 14
56070 Koblenz
Germany
Tel: +49 261 80091 0
Fax: +49 261 80091 49
Email: horst.wagner@netzprojekte.de
Web: www.netzprojekte.de
- Posted by Jon Fanti on February 9th, 2006
Horst Wagner wrote:
<snipped>
Hi all,
Well I made some changes:
I added "spanning-tree portfast bpdguard" as a global configuration to
all my switches. Then on ports that are attached to single hosts (PC or
server) I added "spanning-tree portfast and switchport mode access". For
the moment that seems to have fixed our issues.
I did double check the connections on the uplinks - cables have a way of
moving themselves around! But it's still connected as I described (so no
loop round).
Thanks all for the kind advice,
Jon.
- Posted by anybody43@hotmail.com on February 10th, 2006
This is not at all good.
The port FA 0/1 is implicated in this issue.
It appears to be part of a loop.
Do you have any windows servers (or other)
configured with Dual NIC's and _bridging_?
What about wireless? Do you have any of that?
You would apper without question to have a loop anyway.
If you do a show mac-address you will see what
devices the switch thinks are on which port.
End station ports should have onlt one address
and ports that link switches will have many addresses.
You can then perhaps find out which port (if any)
is incorrectly connected.