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@R1-LAB# show policy-options policy-statement test
from {
protocol static;
tag 10;
}
then accept
root@R1-LAB# show protocols bgp group test
neighbor 1.1.1.2 {
export test;
peer-as 65000;
}
*R2 Config:*
root@R2-LAB# ...icy-statement deny
term deny {
from {
protocol bgp;
community condition1;
}
to {
protocol bgp;
community condition2;
}
then default-action reject;
}
root@R2-LAB# show policy-options community condition1
members "^65000:999$";
[edit]
root@R2-LABa# show policy-options community condition2
invert-match;
members "^65000:.11..$";
root@R2-Lab# show protocols bgp group test
neighbor 1.1.1.1 {
import deny;
peer-as 65000;
}
*R2 show commands:*
root@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@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 [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
