[j-nsp] instance-specific filters for VPLS BUM/flood filtering

[Addy Mathur]

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> 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>   desk (907) 550-8393
>                                                      cell (907) 632-8492
> IP Engineer - ACS
> ------------------------------------------------------------------------
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>