[j-nsp] Policy-options: Logical AND for community values

[Rafael Rodriguez]

Hello list,

I've run into a snag and need some advice.

*Goal:*
Within a policy, reject prefixes that meet two conditions.  All other
prefixes are accepted.

*Conditions (logical AND):*
1)  Prefix must contain a community tag of "65000:999"
2)  Prefix must NOT contain a community tag of "65000:.11.." (regex)

In condition 2) it is much easier for me to describe what I don't want than
it is to describe what I do want (invert-match community).

I currently have this working but I am uncomfortable with the solution as I
don't quite understand why its working :)

Here is the working policy I am uncomfortable with (rejects prefix
10.10.10.10/32):

*The Setup:*
R1 sends R2 various prefixes with community tags.

*R1 Config:*
[edit routing-options static]
route 10.10.10.10/32 {
    discard;
    tag 10;
    community [ 65000:999 65000:52255 ];
}
route 10.10.10.20/32 {
    discard;
    tag 10;
    community [ 65000:999 65000:51155 ];
}
route 10.10.10.30/32 {
    discard;
    tag 10;
    community 65000:51155;
}
route 10.10.10.40/32 {
    discard;
    tag 10;
    community 65000:12345;
}
route 10.10.10.50/32 {
    discard;
    tag 10;
}

root at R1-LAB# show policy-options policy-statement test
from {
    protocol static;
    tag 10;
}
then accept

root at R1-LAB# show protocols bgp group test
neighbor 1.1.1.2 {
    export test;
    peer-as 65000;
}


*R2 Config:*
root at R2-LAB# ...icy-statement deny
term deny {
    from {
        protocol bgp;
        community condition1;
    }
    to {
        protocol bgp;
        community condition2;
    }
    then default-action reject;
}

root at R2-LAB# show policy-options community condition1
members "^65000:999$";

[edit]
root at R2-LABa# show policy-options community condition2
invert-match;
members "^65000:.11..$";

root at R2-Lab# show protocols bgp group test
neighbor 1.1.1.1 {
    import deny;
    peer-as 65000;
}

*R2 show commands:*
root at R2-LAB# run show route receive-protocol bgp 1.1.1.1

inet.0: 15 destinations, 15 routes (14 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.10.10.20/32          1.1.1.1                      100        I
* 10.10.10.30/32          1.1.1.1                      100        I
* 10.10.10.40/32          1.1.1.1                      100        I
* 10.10.10.50/32          1.1.1.1                      100        I


*Results and Questions:*
:) it works (10.10.10.10 is filtered out b/c it has 65000:999 AND does not
have 65000:.11..) but I don’t quite understand the relationship between
‘from’, ‘to’, and ‘then’ in the policy-statement.  From my understand the
‘from’ and the ‘to’ are treated as logical ANDs.  Both need to evaluate to
TRUE.  See highlighted section below, this is where I got the idea of using
‘from’ and ‘to’.  I've never used the 'to' statement, remember being told
that its usually used to verify which level IS-IS prefixes are destined for.
 Anyways, I’d appreciate any feedback and clarification on the ‘from’, ‘to’,
and ‘then’ statements.

root at CR1-TCK1-LAB-Boca# set policy-options policy-statement test ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  dynamic-db           Object may exist in dynamic database
> from                 Conditions to match the source of a route
> term                 Policy term
> then                 Actions to take if 'from' and 'to' conditions match
> to                   Conditions to match the destination of a route

So I am looking for ways/options on accomplishing the listed goals from
above.  Currently I know of two ways, 1) utilizing 'from' and 'to' and 2)
policy subroutines.  Are there other ways, one better than another, etc?
 Thanks for reading.

Cheers,
RR