SPAN/RSPAN issues

Question

Hi All,
I'm looking in to a problem regarding slow response to a file server, post implementation of RSPAN source changes.
SCENARIO
The LAN is a stack of 2/3 3750's on each floor, with a data Vlan per floor and a network wide voice Vlan 300. These access switches are gig fibre connected to two core switches, 6506's. Nortel IP handsets have been deployed and the voice Vlan 300 is being SPAN'ed to record to an IP voice recorder server. No problems there.
However, now there are Softphones deployed on various PC's and in order to facilitate staff relocation throughout the building, WITHOUT having to reconfigure any switch ports each time, the Data Vlan on each floor has also been specified as a source.
Having put additional config in to capture the data Vlan, there appears to be slow response when accessing a file server on a different Vlan. A ping -t that runs while copying a file to the Win 2003 file server actually drops and the copy hangs. If you try this again having either suspended the access switch RSPAN or shifting the file server to the other core switch, it seems to be OK and the difference in the ping response is very apparent
QUESTION
Has anyone come across any performance problems such as this and if so could you shed some light please?
Here's the config from only one of the floors:
DATA Vlan 112
VOICE Vlan 300
Remote SPAN dest Vlan 30
monitor session 1 source vlan 112 , 300
monitor session 1 destination remote vlan 30
Here's the config from the core switch where the voice recorder sits;
interface GigabitEthernet4/2
description *** SPAN destination for Witness CSS01 NIC 1 ***
no ip address
speed 100
duplex full
switchport
spanning-tree portfast
monitor session 1 destination interface Gi4/2
monitor session 1 source remote vlan 30
Kind Regards
Ali

Answer 1

Hello Ali,
I expirienced trouble with 3750 using 1000-BASE-SX and 1000-BASE-LH lasers that gave poor peformance with file transfers.
This was the case on switches that had MLS QoS enabled for IP phones.
The symptoms are described in bug toolkit CSCeg29704. There is a workaround. Upgrading to 12.2(25)SED or higher resolves the problem.
Release Notes
After enabling QOS on 3750 and 3560 switches, certain application (mostly bursty
and TCP based) experience significant performance degradation due to unexpected
packet drops on some of the egress queues.
This is due to initial default egress queue threshold settings
(when qos enabled) not optimized for this type of traffic pattern.
This initial default queue threshold settings (when qos enabled)
thus need to be changed to accommodate these traffic.
Workaround:
Tune the egress queue thresholds parameters to
allocate more to the affected queues.
Specifically, egress queue 2 thresholds need to have the following settings:
Thresholds1 = 200
Thresholds2 = 200
Reserved = 50
Maximum = 400
e.g.
mls qos queue-set output 1 threshold 2 200 200 50 400
mls qos queue-set output 2 threshold 2 200 200 50 400
HTH
Leon
* Please rate useful posts.