You can't do with policy alone, because a policy only gets to see one route
at a time. No amount of complexity changes that (a && b) just ands to gether
two decisions about x/y. If a only looks at x/y, and b only looks at z/w,
then when you're looking at x/y, b will just be ignoring x/y.
However, depending on the details of what you're really trying to
accomplish, you can combine a few features to get the result you're looking
for.
For example, you can make a static route with recursive next hops, and
qualified next hops, and then build a policy that matches on one of the next
hops, and only exports if it finds the right next hop.
So, you make one next hop recursive, and *in* the conditional subnet. For
example if you're trying to say
announce 128.16/16 if 10.10.10/24 does *not* exist
Then you make a static 128.16/16 w/ two next hops, 10.10.10.1, and something
else. Make the preference of 10.10.10.1 good, and the other worse.
Then make a policy that looks for the other next hop for that route, and
announces it only if that next-hop is found. Then, if 10.10.10/24 is in your
routing tables, 10.10.10.1 will be the next hop for the route, and it will
fail the policy.
There are other stunts you can do mucking with route preference, and
possibly using aggregate policies again combined with recursive next hops.
If you have a specific problem your trying to solve, feel free to lay out
the details.
Below an example of the above scenario in action. Note that an aggregate
route with a policy comes close to what you want. Aggregates are triggered
by contributing routes (i.e. more specific routes which the aggregate
overlaps), and you can use policy to decide *which* contributing routes will
actually activate the policy. It takes a little trickery to get a
contributing route to *block* an aggregate, rather than activate it, but
since it has to be a contributing route, and not just any route, I won't get
into it.
-Avram
r1-r2-r3
r2:
interfaces {
so-0/2/0 {
unit 0 {
family inet {
address 11.0.1.2/24;
}
}
}
fe-0/3/0 {
unit 0 {
family inet {
address 11.0.0.2/24;
}
}
}
routing-options {
static {
defaults {
metric 10;
preference 10;
}
route 128.16.0.0/16 {
next-hop 10.10.10.1;
qualified-next-hop 11.0.255.1 {
preference 220;
}
resolve;
preference 210;
}
}
autonomous-system 2;
}
protocols {
bgp {
group one {
export if-no-ten;
peer-as 1;
neighbor 11.0.0.1;
}
}
ospf {
area 0.0.0.0 {
interface so-0/2/0.0;
}
}
}
policy-options {
policy-statement if-no-ten {
term nh-10 {
from {
next-hop 11.0.1.3;
route-filter 128.16.0.0/16 exact;
}
then accept;
}
}
}
Now on r2:
Notice 10.10.10.1/32 (could be a /24, etc)
And notice that 128.16/16 has 2 next hops, but "via so0/2/0"
is the active one.
[edit]
ps@R2# run show route
inet.0: 11 destinations, 13 routes (10 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.1/32 *[OSPF/10] 00:01:31, metric 1
> via so-0/2/0.0
10.255.254.0/24 *[Direct/0] 00:59:17
> via fxp0.0
10.255.254.2/32 *[Local/0] 00:59:17
Local via fxp0.0
11.0.0.0/24 *[Direct/0] 00:59:17
> via fe-0/3/0.0
11.0.0.2/32 *[Local/0] 00:59:17
Local via fe-0/3/0.0
11.0.1.0/24 *[Direct/0] 00:59:17
> via so-0/2/0.0
[OSPF/10] 00:01:31, metric 1
> via so-0/2/0.0
11.0.1.2/32 *[Local/0] 00:59:17
Local via so-0/2/0.0
11.0.255.2/32 *[Direct/0] 00:13:58
> via lo0.0
128.16.0.0/16 *[Static/210] 00:45:17, metric 10
> via so-0/2/0.0
[Static/220] 00:44:50, metric 10
> to 11.0.1.3 via so-0/2/0.0
224.0.0.5/32 *[OSPF/10] 00:59:18, metric 1
[edit]
ps@R2#
At the same time, on R1:
Notice there is no route for 128/16
ps@R1> show route
inet.0: 5 destinations, 5 routes (4 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.255.254.0/24 *[Direct/0] 3w5d 00:55:16
> via fxp0.0
10.255.254.1/32 *[Local/0] 3w5d 00:55:16
Local via fxp0.0
11.0.0.0/24 *[Direct/0] 01:19:25
> via fe-0/3/0.0
11.0.0.1/32 *[Local/0] 01:19:25
Local via fe-0/3/0.0
ps@R1>
Now we go to r3, and kill the announcement for 10.10.10.1.
On r2:
Notice that 10.10.10.1 is missing, 128.16/16, is now using 11.0.1.3 as it's
next hop, and the other next-hop is "unusable." (w/out the "all" keyword, it
wouldn't have been listed)
ps@R2# run show route all
inet.0: 11 destinations, 13 routes (10 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
10.255.254.0/24 *[Direct/0] 01:03:02
> via fxp0.0
10.255.254.2/32 *[Local/0] 01:03:02
Local via fxp0.0
10.255.254.3/32 *[OSPF/10] 00:00:07, metric 1
> via so-0/2/0.0
[...]
128.16.0.0/16 *[Static/220] 00:48:35, metric 10
> to 11.0.1.3 via so-0/2/0.0
[Static/210] 00:49:02, metric 10
Unusable
224.0.0.5/32 *[OSPF/10] 01:03:03, metric 1
And finally, on r1:
Now, notice that 128.16/16 is here.
ps@R1> show route
inet.0: 6 destinations, 6 routes (5 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.255.254.0/24 *[Direct/0] 3w5d 00:59:08
> via fxp0.0
10.255.254.1/32 *[Local/0] 3w5d 00:59:08
Local via fxp0.0
11.0.0.0/24 *[Direct/0] 01:23:17
> via fe-0/3/0.0
11.0.0.1/32 *[Local/0] 01:23:17
Local via fe-0/3/0.0
128.16.0.0/16 *[BGP/170] 00:02:42, MED 10, localpref 100
AS path: 2 I
> to 11.0.0.2 via fe-0/3/0.0
ps@R1>
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:35 EDT