Your right, you can't look at two routes at once, as
policy is evaluated per prefix, but like you said, if
you can creatively setup the aggregate, you can use it
as a variable, and the (&& ||) operators can base your
actions on the variable. Per if you have a generate
route(aggregate in policy) with a contributing
next-hop from a provider...you can match that against
a policy and advertise the generate route based on
that. Correct me if I am wrong.
thanks
--- Avram Dorfman <avram@juniper.net> wrote:
> 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
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:35 EDT