Conditional advertisting to an upstream

Apologies if this is a basic question - I feel that I should
be able to 
figure this out, but have only confused myself more.

We have the following topo:

  <upstream1>----------<upstream2>
       |                    |
  <ext-m7i-1>          <ext-m7i-2>
       |                    |
   <core-1> ------------ <core-2>
       |                    |
      (the rest of the network)-- 155.198.10.0/24
      /
  155.198.0.0/16

The upstreams provide us a default and we route as
appropriate. What I 
want now is for the M7is to conditionally advertise the
various site 
route aggregates based on the adjacency to the neighbouring
core being up.

Specifically I'd rather not "generate" an
aggregate based on the 
presence of a contributing route, since a significant
portion of the 
routes are not subnetted, so I'd have to have two types of
configuration 
and would like to maintain the simplicity. At the moment
we're single 
connected and I'm using static nulls, but obviously I need
these to be 
withdrawn if the link into the core goes down.

Thoughts?

Additionally I have a question related to the multicast AF
for M-BGP. In 
the above example traffic from 155.198.10.0 will go *out*
via core2, 
7i-2 and upstream2 but return traffic will flow in via
upstream1, 7i-2, 
core1 then across to core2.

How must I advertise the multicast routes such that traffic
from 
155.198.10.0 doesn't fail the RPF? Is it sufficient to
advertise 
155.198.0.0/16 to both upstreams? These are GSRs and our
upstream seems 
(ahem) unfamiliar with the possible issues.

Cheers,
Phil
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

On Sun, 15 Apr 2007, Phil Mayers wrote:
> The upstreams provide us a default and we route as
appropriate. What I
> want now is for the M7is to conditionally advertise the
various site
> route aggregates based on the adjacency to the
neighbouring core being up.
>
> Specifically I'd rather not "generate" an
aggregate based on the
> presence of a contributing route, since a significant
portion of the
> routes are not subnetted, so I'd have to have two types
of configuration
> and would like to maintain the simplicity. At the
moment we're single
> connected and I'm using static nulls, but obviously I
need these to be
> withdrawn if the link into the core goes down.

You could use a 'generate' rather than an aggregate route,
and 
generate the generate route based on policy. If you want to
withdraw 
the advertisement if the peer ceases advertising the
default, you 
could use something like (untested):

      generate {
          route 155.198.0.0/16 policy
if-ebgp-default-exists;
      }

      policy-statement if-ebgp-default-exists {
          term only-ebgp-default {
              from {
 		route-filter 0.0.0.0/0 exact;
 		route-type external;
 	     }
              then accept;
          }
          then reject;
      }

> Additionally I have a question related to the multicast
AF for M-BGP. In
> the above example traffic from 155.198.10.0 will go
*out* via core2,
> 7i-2 and upstream2 but return traffic will flow in via
upstream1, 7i-2,
> core1 then across to core2.
>
> How must I advertise the multicast routes such that
traffic from
> 155.198.10.0 doesn't fail the RPF? Is it sufficient to
advertise
> 155.198.0.0/16 to both upstreams? These are GSRs and
our upstream seems
> (ahem) unfamiliar with the possible issues.

If you don't advertise 155.198.10.0/24 out (using any
address family), 
then this should be OK.  If you do, a more specific
advertisement 
overrides the aggregate in Ciscos AFAIR.  I think there is a
hidden 
toggle in Cisco where you can select behaviour if unicast AF
would 
have a more specific route compared to a multicast AF
aggregate.

In any case, you may also need to check that the peers and
upstreams 
of your upstreams (recursively) have information (i.e.
prefer) paths 
which you use for sending packets in the other direction.

-- 
Pekka Savola                 "You each name yourselves
king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash
of Kings
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

Pekka Savola wrote:
> On Sun, 15 Apr 2007, Phil Mayers wrote:
>> The upstreams provide us a default and we route as
appropriate. What I
>> want now is for the M7is to conditionally advertise
the various site
>> route aggregates based on the adjacency to the
neighbouring core being 
>> up.
>>
>> Specifically I'd rather not "generate" an
aggregate based on the
>> presence of a contributing route, since a
significant portion of the
>> routes are not subnetted, so I'd have to have two
types of configuration
>> and would like to maintain the simplicity. At the
moment we're single
>> connected and I'm using static nulls, but obviously
I need these to be
>> withdrawn if the link into the core goes down.
> 
> You could use a 'generate' rather than an aggregate
route, and generate 

I had been confused by the following statement in the JunOS
docs:

"""A generated route becomes active when it
has one or more contributing 
routes. A contributing route is an active route that is a
more specific 
match for the generated destination.... A route can
contribute only to a 
  single generated route."""

Which implies to me that the policy is only applied to
potentially 
contributing routes i.e. in your example below the policy
would never 
"see" the 0.0.0.0/0 since it's not a contributer.
The wording in the 
later docs support this.

Is this not in fact the case?
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

On Mon, 16 Apr 2007, Phil Mayers wrote:
> """A generated route becomes active when
it has one or more contributing
> routes. A contributing route is an active route that is
a more specific
> match for the generated destination.... A route can
contribute only to a
>  single generated route."""
>
> Which implies to me that the policy is only applied to
potentially
> contributing routes i.e. in your example below the
policy would never
> "see" the 0.0.0.0/0 since it's not a
contributer. The wording in the
> later docs support this.
>
> Is this not in fact the case?

You're probably right and I was confused.

There has been some discussion on this on the list before.

Yep, it isn't intended to work this way:
http://puck.nether.net/pipermail/juniper-ns
p/2006-October/007038.html

Some route next-hop tricks that may get around this:
http://atm.tut.fi/list-archive/juniper-nsp/msg00213.html

http://atm.tut.fi/list-archive/juniper-nsp/msg00214.html

(and other messages in the thread)

-- 
Pekka Savola                 "You each name yourselves
king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash
of Kings
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp