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

[adamv0025 at netconsultings.com]

Hi James,

> James Bensley
> Sent: Thursday, December 22, 2016 10:06 AM
> 
> 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?
> 
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. 
  
	
As Saku pointed out, 
Capturing the drop counters from all around the place might indicate where
the drops are happening. 

And for Christmas I wish us all the NPU and FIA telemetry. 
So we can see, ah look the NPU is doing 90% compute utilization in peaks, so
we better not enable SPAN on any of its ports. 
 


adam

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