[c-nsp] rate-limit rspan (6500/sup-720)

[Robert Williams]

Hi all,

Unfortunately the scenario doesn't permit for additional bandwidth / circuits between the locations as we are talking about very long (read: expensive) circuits. We may have to look at outputting to a 1G port, physically-looped to another 1G port which is then going off down the 10G. I'll look at the options for setting DSCP but I can't say I've seen it in there for RSPAN unfortunately.

I was hoping there was a way of policing the RSPAN vlan at the source, as a whole, but it's sounding like it isn't possible.

Thanks anyway!


Robert Williams
Backline / Operations Team
Custodian DataCentre
tel: +44 (0)1622 230382
email: Robert at CustodianDC.com
http://www.custodiandc.com/disclaimer.txt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Phil Mayers
Sent: 12 November 2012 12:41
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] rate-limit rspan (6500/sup-720)

On 12/11/12 08:55, Robert Williams wrote:
> Hi,
>
> I often use rspan sessions to analyse traffic at remote locations but
> the capacity between the analyser and the source is less than the
> 'potential' traffic I could select for analysis. In these cases, I may
> be sourcing from a 10GB port and bringing that traffic to a remote
> location over another 10GB trunk port.
>
> However, there was other (real) traffic on that trunk port before I
> enabled the rspan session, so my additional traffic could now exceed
> the 10GB available in total. Causing drops in the non-rspan traffic as
> it tries to egress the port along with the mirrored rpsan traffic.
>
> Thus my question is, how do you rate-limit traffic before it is placed
> onto the rspan vlan? Or at least reduce its priority such that it has
> no impact at all on all other traffic egressing that port.

I don't know about RSPAN, but ERSPAN lets you set the DSCP. This might help, but I don't know how the originating device behaves w.r.t. output congestion. Presumably it does the right thing...

As Roland has suggested, the best solution is "don't do that" i.e. don't move 10G of SPAN traffic over a 10G production link. Either VACL filter, use separate links or do something "cleverer" (local analyser box, one of those fancy sampling tap thingies, pipe SPAN traffic into a switch with filtering layer2 ACLs & learning disabled before piping it back to you, etc.).
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/