Is ok to disagree as your captures below prove your point and that you are correct.
Apologies for the misinfo.... Andy -----Original Message----- From: Smith W. Stacy [mailto:st...@acm.org] Sent: Wednesday, January 12, 2011 12:02 PM To: Andy Vance Cc: Paul Stewart; juniper-nsp Subject: Re: [j-nsp] Aggregate Routes Revisited 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 u...@host> show configuration protocols bgp group foo { export static-bgp; neighbor 192.168.0.2 { peer-as 2; } } u...@host> show configuration routing-options static { route 192.168.5.0/24 { discard; preference 240; } } autonomous-system 1; u...@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; } u...@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 u...@host> show route advertising-protocol bgp 192.168.0.2 u...@host> configure Entering configuration mode [edit] u...@host# delete routing-options static route 192.168.5.0/24 preference [edit] u...@host# commit and-quit commit complete Exiting configuration mode u...@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 u...@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 u...@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:st...@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.va...@360networks.com >> www.360networks.com >> >> -----Original Message----- >> From: juniper-nsp-boun...@puck.nether.net >> [mailto:juniper-nsp-boun...@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@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp