[j-nsp] Conditional advertisting to an upstream

Pekka Savola pekkas at netcore.fi
Mon Apr 16 05:08:28 EDT 2007


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


More information about the juniper-nsp mailing list