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

Krasimir Avramski krasi at smartcom.bg
Tue Sep 20 12:55:58 EDT 2011


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


More information about the juniper-nsp mailing list