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

[adamv0025 at netconsultings.com]

> James Bensley
> Sent: Thursday, January 12, 2017 5:01 PM
> To: c-nsp
> Subject: Re: [c-nsp] Bug with IOS-XR and SPAN ports?
> 
> On 22 December 2016 at 13:58,  <adamv0025 at netconsultings.com> wrote:
> 
> Hi Adam,
> 
> Super late response, festive period an all that :)
> 
> > I was reading the original post again and now I think the VOQs should
> > have nothing to do with this.
> > ASR9k has a very granular VOQ architecture -that is, VOQs/VQIs per
> > egress port(10GE entity)&fabric-priority-level(3 Levels).
> >
> > Case1:
> > If the SPAN traffic is destined to the same egress physical port and
> > has the same fabric priority as regular traffic, only then the regular
> > traffic will compete with SPAN traffic for a specific FIA VOQ buffer
> > during egress port congestion.
> > (would have to be same egress port just different sub-interface).
> > - Expected behaviour.
> >
> > Case2:
> > If the SPAN traffic is destined to the same egress NPU as regular
> > traffic (just a different port).
> > And the egress NPU gets congested, for example high pps in combination
> > with lot of features enabled, QOS, ABF, NetFlow...
> > Then all traffic (starting from lowest fabric priority first) will
> > experience the effects of backpressure (till the egress NPU can cope
> > with the pps rate).
> > (NPU will also issue WAN backpressure in this case).
> > - Expected behaviour.
> >
> > Case3: (most likely)
> > Ingress NPU is overloaded, for example high pps in combination with a
> > lot of features enabled, QOS, NetFlow and SPAN).
> > In this case NPU will initiate WAN backpressure and the EFD will start
> > dropping packets before they get to NPU's pipeline starting from
> > packets(heads) placed by pre-classifier(ICU TOP) into low priority
> > ICFD queues.
> > (NPU will also issue Fabric backpressure in this case).
> > - Expected behaviour.
> 
> I don't think this is "case 3" an ingress NPU issue (although its really
up to
> Hank and his TAC support to confirm) but reading his original email, in
> monitor session 1 he has 11Gbps of source ports SPAN'ed to 10Gbps
> destination port(s).
> 
> So I am reading it as Case 4:
> The regular traffic ingressing the SPAN source ports is routed to "some"
> destination ports/NPUs. The SPAN traffic is sent to a port on a
potentially
> different line card or NPU to the routed regular traffic.
> When the SPAN port or NPU becomes congest back pressure is triggered
> across the switch fabric to the ingress NPU where it is not
differentiating
> between SPAN traffic and regular traffic.
> 
Your description is a bit ambiguous as you mention, guess you mean egress,
"SPAN port or NPU". 
If it's egress SPAN port, then it's my case1, if it's egress NPU, then it's
my case2.   

If port to which SPAN traffic is destined/spanned to becomes overloaded,
then the resulting backpressure will impact all ingress NPUs but only the
VOQs designated to this particular egress port. 
-so only user traffic destined to this specific 10GE entity(+priority level)
is subject to backpressure along with spanned traffic (Case1). 

If NPU to which SPAN traffic is destined/spanned to becomes overloaded, then
the resulting backpressure will impact all ingress NPUs but only the VOQs
designated to this particular egress NPU. 
-so only user traffic destined to this specific NPU(+priority level) is
subject to backpressure along with spanned traffic (Case2). 


adam

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