[c-nsp] Bug with IOS-XR and SPAN ports?

James Bensley jwbensley at gmail.com
Thu Dec 22 05:06:03 EST 2016


On 15 December 2016 at 14:00,  <adamv0025 at netconsultings.com> wrote:
> Hi,
>
>> James Bensley
>> Sent: Thursday, December 15, 2016 12:29 PM
>> Is it something to do with the central arbiter counting the packets at
> ingress
>> twice (once for the "normal" transit packet and once for the duplicate of
> the
>> packet made for the SPAN session) so when the SPAN destination port
>> becomes congested its dropping the ingress traffic even though the
> original
>> ingress packet is destined for a different non-congested port?
>>

> I think that the central arbiter actually has to count the packets twice to
> keep track of how much is being sent over the fabric as well as to both, the
> original NPU and the SPAN NPU.
>
> The problem however I'd see in how the ingress FIA queues the SPAN traffic
> -SPAN packets should have the lowest fabric priority so should be sitting
> with other/legit low priority packets in the low priority VOQ for a given
> egress NPU.

I think the SPAN traffic should be sitting below legit unmarked
traffic in fact (in an ideal world) as the lowest of the three
priorities for most people will be Internet traffic which customers
are paying for so it shouldn't be dropped because of congestion caused
by a SPAN session (in my opinion).

In the scenario that Hank is describing, I think you are correct that
the arbiter needs to count the packets entering the FIA twice so that
the switch fabric doesn't become congested however it needs to
differentiate between packets that have come from a SPAN source and
those that haven't. In this case with congestion on the SPAN egress
port, dropping the legitimate traffic at ingress is not "right", there
needs to be backpressure within the SPAN session to stop duplicating
the packets (somehow?) until the egress SPAN port has more capacity.
Perhaps another queue priority across the switch fabric?

> Hank,
> Have you tried moving your legit traffic into higher priority fabric queue
> (there are 3 levels + mcast), to see if it helps with the unwanted drops
> please?

I would expect this to work and would interested in the results. I'm
eager to hear what TAC have to say about all these, I'm expecting it
will culminate in a bug that is fixed in a newer release.

Cheers,
James.


More information about the cisco-nsp mailing list