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

[Rafael Rodriguez]

Thanks for replies.  Just if anyone is curious, I went the route of a policy
subroutine:

policy-statement test {
    inactive: term from-to {
        from {
            protocol bgp;
            community condition1;
        }
        to {
            protocol bgp;
            community condition2;
        }
        then default-action reject;
    }
    term subroutine {
        from {
            protocol bgp;
            community condition1;
            policy subroutine;
        }
        then default-action reject;
    }
}
policy-statement subroutine {
    term currentregion {
        from {
            protocol bgp;
            community condition2;
        }
        then accept;
    }
    then reject;
}
community condition1 members "^65000:999$";
community condition2 {
    invert-match;
    members "^65000:.11..$";
}


On Tue, Sep 20, 2011 at 12:55 PM, Krasimir Avramski <krasi at smartcom.bg>wrote:

> import !(condition1 && condition2)
> where condition1 policy ACCEPT first comunity and condition2 policy ACCEPT
> invert-match comunity.
>
> Krasi
> On 20 Sep 2011 17:35, "Rafael Rodriguez" <packetjockey at gmail.com> wrote:
> > 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
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>