[j-nsp] Finding drops

Jason Lixfeld jason-jnsp at lixfeld.ca
Wed Jan 23 07:43:34 EST 2019


> On Jan 22, 2019, at 2:42 PM, adamv0025 at netconsultings.com wrote:
> Maybe any of the show commands in the below, if they show any drops?
> https://kb.juniper.net/InfoCenter/index?page=content&id=KB26519&cat=FIREWALL&actp=LIST <https://kb.juniper.net/InfoCenter/index?page=content&id=KB26519&cat=FIREWALL&actp=LIST>

Nope.  It’s all clean.

> I appreciate you're just concerned with packet count at the moment, but what is interesting is that if you change the rate at which you blast the packet at the box (bigger packets = slower PPS rate) the counters align all of a sudden.
> That sort of indicates that for the 64B stream the packets are dropped by the platform -do you get the confirmation on the RX end of the tester about the missing packets? Not sure if this is about misaligned counters or actually about dropped packets?

The Rx tester shows 76M packets, so it’s only seeing what et-0/0/2 says it’s seeing.

> How I read your test is that presumably this is 40G in and 40G out the same PFE (back to back packets @ 64B or 100B packets) 

It’s 100G in/out.

> So we should just consider single PFE performance but still the resulting PPS rate is noooowhere near the theoretical PPS budget.
> How are the PFEs on 204 linked together (any sacrifices in the PFE BW/PPS budget to account for the fabric)? On MPC7E all 4 PFEs would be connected via fabric.  
> So nothing really adds up here...  shouldn't be happening -not at these rates
> adam

More information about the juniper-nsp mailing list