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

[Keegan Holley]

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.