[j-nsp] Aggregate Routes Revisited
Smith W. Stacy
stacy at acm.org
Wed Jan 12 13:33:05 EST 2011
Hi Paul,
I'm assuming you meant 192.168.5.0/24 instead of 192.168.0.5/24.
I think your confusion arises from the fact that IOS provides several different knobs to do similar, but slightly different, things. In IOS, network statements, aggregate address, prefix lists, distribute lists, route maps, and redistribute statements can all be used to control some piece of the outbound BGP advertisements. In JUNOS, all of these things generally fall under the export routing policy umbrella.
In IOS, the network statement allows you to redistribute a single prefix from one protocol into outbound BGP advertisements. It also allows you tweak some of the BGP attributes in the process. It sounds like your using that functionality to add communities to the routes being redistributed into outbound BGP advertisements. Finally, network statements are evaluated before outbound route maps, so you can combine the two and allow your outbound route map to match on the community added in your network statement. Remember, however, that the network statement is doing the redistribution. If you had only a network statement that didn't apply any community, and had no outbound route-map, the prefix in the network statement would be included in outbound BGP advertisements.
In JUNOS, 'configured' routes (static, aggregate, and generate) can actually have BGP attributes on them. Your configuration under [edit routing-options aggregate] can be thought of simply as a conditional static route. The aggregate route is generated and installed into the local routing table, with the configured community attributes, only if a more specific contributing route is present in the local routing table. That more specific contributing route is the condition. Unlike network statements in IOS, JUNOS aggregate routes are not redistributed into any protocol's outbound route advertisements by default. You must also match that aggregate route in a protocol's outbound export policy for it to be advertised. That's what you are doing by matching the community attributes that are part of the aggregate route.
Since JUNOS doesn't provide a direct equivalent to the network statement, you must use export policy to redistribute routes from another protocol (as you want to do with the OSPF /24). You must also use this same export policy to control the other prefixes you do or do not want to advertise.
All this said, here are a couple ways you can do it.
1) Create a separate policy that matches your 192.168.5.0/24 OSPF prefix and adds your communities. Apply this policy in a policy change to all BGP sessions where you want the route advertised. In the policy chain, make sure you place the policy to match the OSPF route BEFORE the policy to match on communities.
[edit protocols bgp]
user at host# show
group level3 {
export [ redist-some-ospf outbound-level3-v4 ];
neighbor 1.2.3.4 {
peer-as 3356;
}
}
[edit policy-options]
user at host# show
policy-statement outbound-level3-v4 {
term lvl3-1 {
from community our_nets;
then {
as-path-prepend 11666;
accept;
}
}
term lvl3-2 {
from community customer_nets;
}
term level3-2 {
then accept;
}
term lvl3-3 {
then reject;
}
}
policy-statement redist-some-ospf {
term 1 {
from {
protocol ospf;
route-filter 192.168.5.0/24 exact;
}
then {
community add our_nets;
}
}
}
community customer_nets members 11666:4000;
community our_nets members 11666:5000;
2) Add this as another term in your existing policy. Make sure the term comes before the term that matches on community.
[edit protocols bgp]
user at host# show
group level3 {
export [outbound-level3-v4 ];
neighbor 1.2.3.4 {
peer-as 3356;
}
}
[edit policy-options]
user at host# show
policy-statement outbound-level3-v4 {
term lvl3-0 {
from {
protocol ospf;
route-filter 192.168.5.0/24 exact;
}
then {
community add our_nets;
}
}
term lvl3-1 {
from community our_nets;
then {
as-path-prepend 11666;
accept;
}
}
term lvl3-2 {
from community customer_nets;
}
term level3-2 {
then accept;
}
term lvl3-3 {
then reject;
}
}
community customer_nets members 11666:4000;
community our_nets members 11666:5000;
Hope this helps.
--Stacy
On Jan 12, 2011, at 9:58 AM, Paul Stewart wrote:
> 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
More information about the juniper-nsp
mailing list