Victor,

I agree with you on many points, but I am being asked to set this up.  My demarc is at the switch, and I have no involvement with or input to the design of the device at the other end of the span session.  I'm trying to find any undesirable side effects to the performance or health of the switch before I configure the request.  Would rather avoid any surprises.  My gutt reaction is that I don't like it, that the SPAN feature is not meant for this purpose, but that's not enough to turn down the request at layer 8 and 9.

Regards.

I understand the political component, especially when you have non-technical meatballs trying to put on a dog-and-pony for their bosses, who want to play "CYA."

That having been said, I dont specifically know what the ramifications would be of doing what you want, I am not sure anyone can answer that with absolute certainty. it is something you would have to test in a lab environment.

Instead of using the SPAN feature on the switch itself, they can consider investing in a probe appliance and installing it in series with one of the distribution layer's uplinks to the core, and perhaps between the L2 trunks between the access and distribution layers.

That's more along the lines of an acceptable solution when the requirement is permanent.

Victor

Victor,

The request calls to view all data traffic on the edge vlans, so it has to be on the DR itself since it (the DR) will drop some traffic (broadcasts, invalid packets, etc.)    Also, the uplinks links to the core are running MPLS (LDP) so at that point the traffic is no longer tagged by dot1q which makes it difficult to trace back to where it comes from.

I did think of putting fiber taps on each downlink to the AS and use a different switch to aggregate the captured traffic, but with over 300 AS with dual uplinks each the cost and complexity would not be feasible.

I appreciate your input

Hello A. Paradela,

>> Other than the obvious oversubscription and resulting dropped traffic on  the SPAN traffic, has anyone experienced any side effects by sending so  much traffic / vlans out a SPAN session?   I'm thinking CPU / memory /  other switch resources / etc.

We have seen that if we try to push 3 Gbps of traffic over a single GE SPAN destination port sup720 cpu hits 100% and we had to disable it.

The device had become almost non responsive and it was near to be unmanageable.

We had to remove the SPAN session.

So your concerns are legitimate and if the aggregate traffic volume is high this configuration is not sustainable over long times.

our system is a sup 720 3BXL with IOS image:

sh ver | inc image
System image file is "disk0:s72033-adventerprisek9_wan-mz.122-18.SXF14.bin"

we have CSM and FWSM on it and we had an IDS on the destination port.

Hope to help

Giuseppe

Hi Guiseppe,

Wow, I did not think it would get that bad.  A few questions.

Was it the RP's CPU that spiked? (sh proc cpu)

Did you ever escalate to TAC or look into it further to find the root cause?

Was the SPAN source a physical port or a VLAN, and how many of them?

Was the CPU load relative to the traffic load?

CCO docs actually say there's no performance hit with SPAN on the 6500, but also say that SPAN traffic competes with user traffic for all switch resources.

Thank you in advance.

Giuseppe,

Thanks so much for the info.

Regards