[j-nsp] Aggregate Routes Revisited
Paul Stewart
paul at paulstewart.org
Wed Jan 12 16:01:45 EST 2011
Just wanted to write back to the list and say THANK YOU! I had already
created a policy very similar to what you had suggested - but - when I added
it to the outbound policy for the upstream I didn't pay attention to the
order it was applied.
With it correctly applied *before* the existing "outbound-level3-v4" it
worked - one minor thing I did wrong as well was I had added a reject
statement at the end of my first policy which of course caused the *only*
prefix to be announced the /24 .. oops ;)
I went with the 2 different export policies approach so that I can adjust
the ospf to bgp policy and not interfere with the existing policies and vice
versa.
Again - thank you....
Paul
-----Original Message-----
From: Smith W. Stacy [mailto:stacy at acm.org]
Sent: Wednesday, January 12, 2011 1:33 PM
To: Paul Stewart
Cc: 'juniper-nsp'
Subject: Re: [j-nsp] Aggregate Routes Revisited
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