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 <r...@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp