Except I am running network-services ip not enhanced-ip, and 10.4R10 now R11 (PR lists R9 as "fixed") and am seeing shared policers.
On 11/14/12 8:19 AM, Addy Mathur wrote: > Folks: > > When Trio MPCs were released, original behavior pertaining to policer > behavior on VPLS instances was different from that observed on I-CHIP > DPCs (as has been uncovered in this thread). This was changed via > PR/674408, which should now be externally viewable. It changes the > default Trio MPC behavior to be more in line with I-CHIP DPC default. > > https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR674408 > > Regards, > Addy. > > On Fri, Nov 9, 2012 at 2:57 PM, Christopher E. Brown > <chris.br...@acsalaska.net <mailto:chris.br...@acsalaska.net>> wrote: > > > Please share case #, I have same complaints in discussion with our SE > and up that chain. > > Personally I think they need to add "instance-specific" as a keyword to > the policer to make them shared or not-shared by choice. 95% of the > time I need unshared, but can think of a few cases where shared sould be > useful. > > > On 11/8/12 7:06 AM, Saku Ytti wrote: > > > >>> In my mind, the default is fine. It is consistent with normal > behavior > >>> and there are times when a shared policer would be desired. The > lack of > >>> a instance specific option though, that is stupid beyond belief, > >>> shocking surprise. > >> > >> To me the biggest problem is, you cannot know if instance > policers are > >> shared or not, as it is version dependent. > > > > I opened JTAC case (I can unicast case# if you want to pass it to your > > account team). > > > > Query: > > ---- > > Case A) > > > > # show firewall filter PROTECT-FROM_IP_OPTION > > > > term police-ip-options { > > > > from { > > > > ip-options any; > > > > } > > > > then { > > > > policer POLICE-IP_OPTIONS; > > > > count police-ip-options; > > > > } > > > > } > > > > term accept-all { > > > > then { > > > > count accept-all; > > > > accept; > > > > } > > > > } > > > > > > > > # show firewall policer POLICE-IP_OPTIONS > > > > if-exceeding { > > > > bandwidth-limit 3m; > > > > burst-size-limit 3200000; > > > > } > > > > then discard; > > > > > > > > set routing-instances RED forwarding-options family inet filter > PROTECT-FROM_IP_OPTION > > > > set routing-instances BLUE forwarding-options family inet filter > PROTECT-FROM_IP_OPTION > > > > > > > > Will RED and BLUE share 3Mbps, or will each get own 3Mbps? > > > > > > > > > > > > Case B) > > > > > > > >> ...amily vpls filter PROTECT-UNKNOWN_UNICAST > > > > > > term unknown_unicast { > > > > from { > > > > traffic-type unknown-unicast; > > > > } > > > > then { > > > > policer POLICE-UNKNOWN_UNICAST; > > > > accept; > > > > } > > > > } > > > > term accep { > > > > then accept; > > > > } > > > > > > > >> show configuration firewall policer POLICE-UNKNOWN_UNICAST > > > > if-exceeding { > > > > bandwidth-limit 42m; > > > > burst-size-limit 100k; > > > > } > > > > then discard; > > > > > > > > set routing-instances GREEN forwarding-options family vpls filter > input > > PROTECT-UNKNOWN_UNICAST > > > > set routing-instances YELLOW forwarding-options family vpls filter > input > > PROTECT-UNKNOWN_UNICAST > > > > > > > > Will GREEN, YELLOW share 42Mbps or get own 42Mbps policers? > > ---- > > > > > > > > JTAC response > > ---- > > Query: If you configure same FW with policer to multiple > instances, what is expected result? Should policer be shared or > should it be dedicated per instances? > > JTAC: It will be dedicated per instance. In your example RED and > BLUE will consume 3MB independently. > > --- > > > > > > > > > > But as per my own testing, I know IP-OPTIONS policer was shared in > 10.4 (which > > is what I want for IP options). And VPLS policer I want > not-shared, as in 11.4. > > > > > > > -- > ------------------------------------------------------------------------ > Christopher E. Brown <chris.br...@acsalaska.net > <mailto:chris.br...@acsalaska.net>> desk (907) 550-8393 > <tel:%28907%29%20550-8393> > cell (907) > 632-8492 <tel:%28907%29%20632-8492> > IP Engineer - ACS > ------------------------------------------------------------------------ > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > <mailto:juniper-nsp@puck.nether.net> > https://puck.nether.net/mailman/listinfo/juniper-nsp > > -- ------------------------------------------------------------------------ Christopher E. Brown <chris.br...@acsalaska.net> desk (907) 550-8393 cell (907) 632-8492 IP Engineer - ACS ------------------------------------------------------------------------ _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp