[j-nsp] Aggregate Routes Revisited

[Andy Vance]

Paul,

Assuming you have a static route policy to pick up static routes into
BGP, couldn't you just pin that /24 route down to discard, with a high
priority of 240 or so, to inject it into BGP, then allow the routing
table to use the OSPF route for packets destined to that /24 once
received? 

Cheers,

Andy Vance, IP Engineer  
360networks
2101 4th Ave., Suite 2000
Seattle, WA 98121
253.307.7546 (c)
andy.vance at 360networks.com
www.360networks.com

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Paul Stewart
Sent: Wednesday, January 12, 2011 8:59 AM
To: 'juniper-nsp'
Subject: [j-nsp] Aggregate Routes Revisited

Hi folks..

 

Earlier this year I posed a question to the list and never did things
working the way I expected - so I'm revisiting the topic.  I got several
helpful replies from folks but either am thick headed or misunderstood
;)

 

In our Cisco network, we use the "network" statement in our BGP
configurations.  I'm looking to do similar on our MX platforms - my
"saving
grace" to date is that the Cisco 7600's are still online and
contributing
the routes.  The 7600's are coming out shortly and I need to resolve
this ;)

 

Our BGP export is community driven and working fine today (with the
contributed routes from the 7600 platform).  Our own routes are tagged
with
11666:5000 and our transit customers are tagged with 11666:4000 (both
have
some additional tags but these catch all - ie 5001 5002 etc)

 

Typical upstream connection looks like this:

 

type external;

description Level3;

advertise-inactive;

import inbound-level3-v4;

export outbound-level3-v4;

neighbor x.xx.xxx.x {

    authentication-key "xxxxxxxxxxxxxxxxxxxxxxxxx"; ## SECRET-DATA

    peer-as 3356;

}

 

Typical export policy to an upstream looks like this (in this case
Level3
which we are prepending once at the moment):

 

term lvl3-1 {

    from community our_nets;

    then {

        as-path-prepend 11666;

        accept;

    }

}

term lvl3-2 {

    from community customer_nets;

    then accept;

}

term lvl3-3 {

    then reject;

}

 

So now comes my problem and this is where I start to get confused with
the
aggregate route options.

 

{master}[edit routing-options aggregate]

route 192.168.0.0/19 community [ 11666:5000 11666:5001 ];

 

This works today - we see the entire /19 exported to our
upstreams/peers.

 

Now, in our OSPF tables we have 192.168.0.5/24 for example which we also
want to advertise upstream.

 

If I add "route 192.168.0.0/19 community [ 11666:5000 11666:5001 ]" to
the
aggregate, this won't work as I understand it because there isn't a more
specific route to contribute towards it's existence.  I opened a JTAC
ticket
and they suggested a policy similar to:

 

term bgp1 {

    from {

        protocol ospf;

        route-filter 192.168.0.5/24 exact;

    }

    then {

        community add our_nets;

        accept;

    }

}

term bgp99 {

    then reject;

}

 

 

This doesn't work neither - there is no BGP route for that particular
192.168.0.5/24 for it to export.

 

So how do I "inject" this /24 into the BGP tables with a community so
that
it exports?  I keep going around in circles on this one ;)

 

Thanks for your patience ;)

 

Paul

 

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp