[j-nsp] Aggregate Routes Revisited

[Andy Vance]

If Paul has an export policy picking up static routes, it should.  An
export policy such as this

   policy-statement static-bgp {
        term static-routes {
            from {
                protocol static;
                tag <if a tag value is preferred>
                route-filter 192.168.5.0/24  exact;
            }
            then {
                community add <community value to add>;
                next-hop self <if next-hop self is required>
                accept;
            }
        }
        term next-policy
            then {
                next policy;
            }
        }

and applied as an export policy on the bgp groups, where it is needed,
should pick up the static route set to discard and allow it to be
exported to the neighbors as it is a valid static route known by
protocol static.  Agreed it isn't the best route in the routing table,
the OSPF route is, and will not be used for forwarding.

I don't have a lab available to test quickly, I'm going from memory, I
could be wrong...

Andy



-----Original Message-----
From: Smith W. Stacy [mailto:stacy at netfigure.com] 
Sent: Wednesday, January 12, 2011 10:36 AM
To: Andy Vance
Cc: Paul Stewart; juniper-nsp
Subject: Re: [j-nsp] Aggregate Routes Revisited

I don't think this will accomplish what Paul is asking for.

The static route /w preference 240 will not become the active route as
long as the OSPF route for the same prefix is present, and only active
routes are evaluated by the export policy. 

--Stacy


On Jan 12, 2011, at 10:19 AM, Andy Vance wrote:

> 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
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp