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

[adamv0025 at netconsultings.com]

Hi James,

Sorting through my backlog on cisco support forum...
Looks like Hank had also 1:1 netflow enabled on the source NPU while doing
RX+TX mirroring, so that's tripling the pps rate through the NPU (so it is
the case of ingress NPU overload after all).
Also it's actually not tripling the pps rate through the NPU per se,
because:
Xander:
If you add qos, acl, etc, those feats aren't applied to the spanned packet,
hence the performance hit is not 50% on top of the performance hit you are
getting from normal traffic forwarding.

Though the question still remains, why it is a problem all of a sudden when
upgrading from 5.1.3 to 5.3.3.

But most important for our discussion is:
Xander:  
note that from fab (egress) or from line (ingress) are always high priority
for the NPU to process. pipeline replication (eg span) is lower priority. so
spanned traffic would never push away in/egress traffic

Need to ask Xander where are the recirculated packets inserted into the
NPU's pipeline, whether via the feeder queues (via ICU and queued at the
ICFDQs) as normal WAN traffic -but there are only 3 priority levels
currently used (out of 4) so not sure how the above statement holds true.
Or maybe there are dedicated ICFDQs with lowest possible priority for
recirculated traffic  so that ingress TM can let these queues to be starved
out?
But m-cast could also be recirculated -so would it be treated with lowest
possible priority at the NPU's feeder queue in that case?   

adam

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