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

[adamv0025 at netconsultings.com]

Hi,

> James Bensley
> Sent: Thursday, December 15, 2016 12:29 PM
> 
> On 14 December 2016 at 21:48, Hank Nussbacher <hank at efes.iucc.ac.il>
> wrote:
> > We have had a TAC case open for a month and they were able to
> > reproduce it just once, where we have been hit by it now twice.
> > There seems to be some unknown threshold that needs to be crossed
> > before the ingress SPANned port starts losing pkts silently.
> > We might very well have to downgrade because of this.
> 
> Thanks for the update Hank. I kept this thread marked in my inbox and was
> going to ask you if you'd had any progress with it. I simply haven't had
the
> time of late but some pending QoS testing I have lined up for ASR9000s
might
> be impacted by said bug so I am curious about the progress of this issue.
> 
> 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.

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? 


adam


netconsultings.com
::carrier-class solutions for the telecommunications industry::