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]
u...@host# show
group level3 {
export [ redist-some-ospf outbound-level3-v4 ];
neighbor 1.2.3.4 {
peer-as 3356;
}
}
[edit policy-options]
u...@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]
u...@host# show
group level3 {
export [outbound-level3-v4 ];
neighbor 1.2.3.4 {
peer-as 3356;
}
}
[edit policy-options]
u...@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@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
