Showing results for 
Show  only  | Search instead for 
Did you mean: 

Experience with Ingress SVI based SPAN configuration?

Customer has an AMD under sustained traffic load of ~7-8Gb/s on a 10G SPAN.

SPAN consists of two port channels of HA Switch to firewall. (DC ingress traffic go into switch, firewall, back into switch, and further in to a DC). This means the SPAN also get's traffic double.
The AMD has a high CPU load (~80%). We only watch <10% of the traffic.

The network team suggests that another approach may be a solution, by using an Ingress SVI based SPAN configuration. Does anyone has experience with this approach?

What is the impact (both positive, and negative) on AMD measurements and CAS reported traffic?



Hi Frans.

I can't say that I know anything of the Environment you a mention but a SPAN based on Ingress "should" provide you with less duplicates - at least if I understand just remotely what it does.

SVI seems to be related to VLAN ACLs which is good news as (my own understanding) you would probably only get Ingress from a single VLAN (as opposed to all traffic as I think thts what you get now) by using what they say - but double check with them first.



A few comments:

- When doing ingress only make sure you are still able to capture the request AND response in the traffic otherwise the AMD will have no way to measure response time. Instead, what you'll possibly see is a bunch of errors as the AMD would expect to see both sides of the conversation.

- In regards to your traffic quality, if you see a high level of duplicates, the AMD will have to de-duplicate, which is very CPU intensive (hence your high CPU stat). The best approach, in my opinion, is to fix those SPAN feeds (i.e. rethink placement and settings) so that you are eliminating noise from the source instead of compensating for it downstream (AMD dedup). This will also reduce your traffic volumes, again freeing up CPU.

- In regards to SVI or any port replication for that matter, make sure as those changes are made you watch out for any drops, errors, overruns on the SVI itself. Any drops or overruns are on that interface and will never make it to the AMD, which would effect the quality of the measures as it can only measure on what it receives.

Hope this helps.