Limit on creating SPAN ports on a 4500x switch

[bberry]

We are looking at deploying a new product that requires a SPAN port to listen to and capture all traffic on a switch. I currently have a 4500x as my core switch and have two span session defined. I currently have 32 VLANs defined.

monitor session 1 source vlan 1 - 3 , 7 , 10
monitor session 1 destination interface Te1/1/7
monitor session 1 filter packet-type good rx
monitor session 2 source vlan 4
monitor session 2 destination interface Te1/1/10
monitor session 2 filter packet-type good rx

I know I can create additional sessions but in order to capture all traffic on the switch am I correct in saying I will need to create with all my VLANs as a source? Can a SPAN session handle that much traffic or better yet if I start with just a few and slowly add more how can I measure the impact on the switch? This is my core switch.

Brent

[Philip D'Ath]

This sounds like a poorly designed product that requires every network packet to be replicated to it.

I would start slowly and add more and more VLANs to gauge the impact.

[bberry]

The product is CyberLens. It is a network inventory type tool but instead of discovering just IP based endpoints it will also discover Industrial Control Systems (ICS) and is completely passive. It identifies devices based upon their conversations and listens to flows to identify traffic patterns. It seems to be a cool tool but if Management wants it to monitor EVERYTHING then I need to look into the limitations of what I can push through the span port. 

[Philip D'Ath]

Does it plug into a 10Gbe port on the 4500?  Is it even capable of handling 10Gbe of traffic being thrown at it?  That is a lot of data.

[bberry]

The VM we are standing up to install the software on only has a 1G network card. My original intent was to do as you said start small and then add. But I am not sure what to monitor to see when I start getting a performance impact especially since I have other ports that are spanning the some of the same VLANs for other reasons.

[Philip D'Ath]

This is not going to work well.  You want to mirror an entire 4500 through a single 1Gbe port.  Unless the total aggregate through for the device is less than 1Gb/s I suspect you are going to get a lot of dropped packets on the span output port.

[pwwiddicombe]

Another issue is there will be duplications, if you monitor both sides of the conversation (i.e. both ports involved).  Without knowing the application, is most of the interesting traffic to/from servers, or truly directly client to client?  You might be able to get away with monitoring only server ports and uplinks; not every device ?

[bberry]

This is what one of our new network admins is saying to management and almost has them thinking that because of the way Cisco architecture is created there is no way this would impact the overall performance of the switch. It would only impact the single SPAN port and cause a drop in packets. We are running 4500x switch platform.He is basing his facts on the following ...

Just wanted to share some information:

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41.html#anc22

The buffer setup for the 4500x is rather unique and the site sort of breaks it down. The information below is for the 4500, the type of switch we have the SPAN on.

Catalyst 4500/4000 Series
Architecture Overview
The Catalyst 4500/4000 is based on a shared-memory switching fabric. This diagram is a high-level overview of the path of a packet through the switch. The actual implementation is, in fact, much more complex:
…
Performance Impact
With use of the SPAN feature, a packet must be sent to two different ports, as in the example in the Architecture Overview section. The send of the packet to two ports is not an issue because the switching fabric is nonblocking. If the destination SPAN port is congested, packets are dropped in the output queue and are correctly released from the shared memory. Therefore, there is no impact on the switch operation.

[Asim Pandey]

its not a requirement that any host that plugs into a 10 gig port has to have a 10 gig interface itself, and that the switch will push 10 gig data towards it, also the fact that the product or the tool is looking for all network traffic is a bad idea, in many cases its required, so at best the volume of traffic mirrored will cause dropped packets on the destination port and not cause any kind of performance impact on the switch.

How much data a host receives and decides to cut off after a certain point is upto the host, 10 gig or no 10 gig.