[j-nsp] instance-specific filters for VPLS BUM/flood filtering
Christopher E. Brown
chris.brown at acsalaska.net
Wed Nov 14 15:08:28 EST 2012
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.brown at acsalaska.net <mailto:chris.brown at 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.brown at acsalaska.net
> <mailto:chris.brown at 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 at puck.nether.net
> <mailto:juniper-nsp at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
--
------------------------------------------------------------------------
Christopher E. Brown <chris.brown at acsalaska.net> desk (907) 550-8393
cell (907) 632-8492
IP Engineer - ACS
------------------------------------------------------------------------
More information about the juniper-nsp
mailing list