What version of JunOS were you running? Any interesting logs/stats from the DPC itself?
2012/5/30 Matjaž Straus Istenič <[email protected]> > 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 <[email protected]> > > > >> 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 <[email protected]> > 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 [email protected] > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
