[j-nsp] Community matching policy

[Andrew Khan]

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