[j-nsp] traffic drops to 8 Gb/s when a firewall filter is applied

[Matjaž Straus Istenič]

Hi list,

no, this is not a joke ;-) -- our problem disappeared when FPC was _power-cycled_ after almost a year uptime. JTAC and the local Juniper partner were very helpful in the troubleshooting and they even supplied a new FPC for a test. We replicated the same behaviour on two MXs. We still don't know what caused the problem. Hope new FPCs with a higher revision number are immune to this kind of behaviour.

Thank you all for your feedback,
Regards,

	Matjaž

On 15. dec. 2011, at 03:04, Keegan Holley wrote:

> I
> 
> 
> 2011/12/14 Richard A Steenbergen <ras at e-gerbil.net>
> 
>> On Fri, Dec 09, 2011 at 01:19:54PM -0500, Keegan Holley wrote:
>>> Yea but it should have enough silicon to do simple policing in
>>> hardware unless you have every single other feature on the box
>>> enabled. If a policer with no queueing, and no marking etc, caused
>>> throughput to decrease by 20% across the board I'd inquire about their
>>> return policy.  Hopefully, it's the policer config.  Most of my 10G
>>> interfaces do not require policers, but I've got 1G interfaces with
>>> hundreds of logicals each with a unique policer.
>> 
>> Unfortunately not... There are all kinds of ways to make I-chip cards
>> not deliever line rate performance even with relatively simple firewall
>> rules, and it's very poorly logged when this does happen. Admittedly
>> I've never seen a simple "then accept" push it over the edge, but maybe
>> it was RIGHT on the edge before... Try looking for some discards, such
>> as WAN_DROP_CNTR, on the *INGRESS* interface (i.e. not the one where you
>> added the egress filter). For xe-x/y/0 do:
>> 
>> start shell pfe network fpc<x>
>> show ichip <y> iif stat
>> 
>> example:
>> 
>> Traffic stats:
>>            Counter Name            Total           Rate      Peak Rate
>>  ---------------------- ---------------- -------------- --------------
>>              GFAB_BCNTR 4229125816477883         949530     1276098290
>>                KA_PCNTR                0              0              0
>>                KA_BCNTR                0              0              0
>> Discard counters:
>>            Counter Name            Total           Rate      Peak Rate
>>  ---------------------- ---------------- -------------- --------------
>>           WAN_DROP_CNTR              298              0             82
>>           FAB_DROP_CNTR             1511              0            419
>>            KA_DROP_CNTR                0              0              0
>>          HOST_DROP_CNTR                0              0              0
>> 
>> --
>> Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
>> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
>> 
>> 
> 
> I see your point, but I'd still be surprised if a defaulted box with a
> "then accept" filter would drop by this much.  You could see the be queue
> discarding packets in the sh int output.  The be queue is given 95% of the
> buffer in the default schedule map which still leaves 1G plus unaccounted
> for.  Maybe it's a little bit of both.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp