[j-nsp] Aggregate Routes Revisited

Smith W. Stacy stacy at acm.org
Wed Jan 12 15:01:53 EST 2011


Sorry, but I still disagree with you. Only the active route in the routing table is evaluated by export policy. I think the captures below illustrate my point.

--Stacy


user at host> show configuration protocols bgp 
group foo {
    export static-bgp;
    neighbor 192.168.0.2 {
        peer-as 2;
    }
}

user at host> show configuration routing-options 
static {
    route 192.168.5.0/24 {
        discard;
        preference 240;
    }
}
autonomous-system 1;

user at host> show configuration policy-options policy-statement static-bgp 
term static-routes {
    from {
        protocol static;
        route-filter 192.168.5.0/24 exact;
    }
    then {
        community add our_nets;
        next-hop self;
        accept;
    }
}
term next-policy {
    then next policy;
}

user at host> show route 192.168.5.0/24 

inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.5.0/24     *[OSPF/150] 00:01:16, metric 0, tag 0
                    > via lt-0/0/0.2
                    [Static/240] 00:18:09
                      Discard

user at host> show route advertising-protocol bgp 192.168.0.2 

user at host> configure 
Entering configuration mode

[edit]
user at host# delete routing-options static route 192.168.5.0/24 preference   

[edit]
user at host# commit and-quit 
commit complete
Exiting configuration mode

user at host> show route 192.168.5.0/24                          

inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.5.0/24     *[Static/5] 00:00:10
                      Discard
                    [OSPF/150] 00:02:06, metric 0, tag 0
                    > via lt-0/0/0.2

user at host> show route advertising-protocol bgp 192.168.0.2    

inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
  Prefix		  Nexthop	       MED     Lclpref    AS path
* 192.168.5.0/24          Self                                    I

user at host> 



On Jan 12, 2011, at 12:19 PM, Andy Vance wrote:

> 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
> 




More information about the juniper-nsp mailing list