[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