[j-nsp] Community matching policy

[Dave Bell]

Yes, that's what that documentation is saying. You probably don't want a
single community statement then.

Regards,
Dave


On 31 March 2014 13:13, Andrew Khan <good1uzi at outlook.com> wrote:

> Thanks, Dave! Your table is awesome and clarified my doubts and clicked
> into my mind :) On your query, "It may be possible to add the two
> communities into one community statement. I'm unsure how exactly that will
> behave though"
>
> let's say something like
> community A members [ 100:100 101:101 ];   // pretty much  (100:100 AND
> 101:101) //
>
>  In that case,  the route must have a community that matches 100:100 and a
> community that matches 101:101
>
> http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policy-bgp-communities-extended-communities-evaluation-in-routing-policy-match-conditions.html
>
> Kind regards,
>
>
> ------------------------------
> Date: Mon, 31 Mar 2014 12:59:57 +0100
>
> Subject: Re: [j-nsp] Community matching policy
> From: me at geordish.org
> To: good1uzi at outlook.com
> CC: krasi at smartcom.bg; juniper-nsp at puck.nether.net
>
>
> The logic of !A OR !B makes my head hurt, so its simple to write out a
> truth table to work out exactly what it does.
>
> A | B | !A OR !B
> -----------------------
> T | T | F
> T | F | T
> F | T | T
> F | F | T
>
> This makes it clear that !A OR !B is identical to !(A AND B)
>
> I don't think there is any way to do what you are interested in with the
> invert-match statement. I would just do something like this
>
> term A {
>  from {
>     community [ A B ];
>  }
>  then accept;
> }
> reject;
>
> community A {
>   members 100:100;
> }
> community B {
>  members 101:101;
> }
>
> It may be possible to add the two communities into one community
> statement. I'm unsure how exactly that will behave though.
>
> Regards,
> Dave
>
>
> On 31 March 2014 12:47, Andrew Khan <good1uzi at outlook.com> wrote:
>
> In addition to my last question, what I don't understand is that !A OR !B
> <=> !(A AND B) /// how come it became AND operation rather than logical
> OR///
>
> From Juniper documentation:
> You can include the names of multiple communities in the community match
> condition. If you do this, only one community needs to match for a match to
> occur (matching is effectively a logical OR operation).
>
> Is it invert-match causing this behavior? What if I don't use
> invert-match, will it be a logical OR operation e.g. A OR B <=> A OR B or
> will it be A OR B <=> (A AND B)
>
> Thanks
>
>
>
> > From: good1uzi at outlook.com
> > To: krasi at smartcom.bg
> > Date: Mon, 31 Mar 2014 11:00:48 +0000
> > CC: juniper-nsp at puck.nether.net
> > Subject: Re: [j-nsp] Community matching policy
> >
> >
> >
> >
> > Hello Krasi,
> > Thanks for the reply, appreciated. Sorry I did not mention in my first
> email that I'm trying to find a workaround while using invert-match. Any
> idea on achieving the same results when using invert-match.
> >
> > Kind regards,
> >
> >
> > Date: Mon, 31 Mar 2014 13:41:40 +0300
> > Subject: Re: [j-nsp] Community matching policy
> > From: krasi at smartcom.bg
> > To: good1uzi at outlook.com
> > CC: juniper-nsp at puck.nether.net
> >
> > A match 100:100B match 101:101 Your TEST1 term match on !A OR !B <=> !(A
> AND B), so it effectively rejects every route that has NO communities
> 100:100 AND 101:101 (at the same time)
> > Your target is to accept A OR B, so you can first match and accept on
> these communities (TEST1 OR TEST2 defined without invert-match) and then
> reject everything else.
> > Best Regards,
> > Krasi
> >
> > On 31 March 2014 12:10, Andrew Khan <good1uzi at outlook.com> wrote:
> >
> > Hi -
> >
> >
> >
> > Let's say I want to reject everything except the following communities:
> >
> >
> >
> > Either 100:100
> >
> > OR 101:101
> >
> > OR both 100:100 101:100
> >
> >
> >
> > Tried to setup something:
> >
> >
> >
> > [edit policy-options]
> >
> > policy-statement TEST {
> >
> >       term TEST1 {
> >
> >           from community [ TEST1 TEST2 ]; ///////Is not it logical OR,
> and matching everything except what I want because of invert-match//////
> >
> >            then reject;
> >
> >        }
> >
> >       term TEST2 {
> >
> >      then accept;   //// And then this should accept what I wanted /////
> >
> >    }
> >
> > }
> >
> >
> >
> > [edit policy-options]
> >
> >    community TEST1 {
> >
> >       invert-match;
> >
> >        members 100:100;
> >
> >    }
> >
> >    community TEST2 {
> >
> >        invert-match;
> >
> >        members 101:101;
> >
> >    }
> >
> >
> >
> > However it is rejecting everything. Any thoughts what I'm missing here
> or perhaps the approach is not correct.
> >
> >
> >
> > Thanks in advance.
> >
> >
> >
> >
> >
> > _______________________________________________
> >
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> >
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
> >
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>