[j-nsp] BCP for anchoring local prefixes for redistribution into BGP

[Mark Tinka]

On Wednesday 02 December 2009 03:40:24 am Jason Lixfeld wrote:

> In Cisco land, I'm used to something like this:

Even your IOS configuration could be streamlined further,
but that is likely beyond the scope of your question :-).

I'd started typing out a response with an example of what we do,
and then I realized that given how flexible the JUNOS's policy
framework is, how you choose to design your routing policy would
be a matter of personal philosophy and style. So I stopped,
because some of the stuff we do is really kinky :-).

> There's no direct JunOS equivalent to network x mask y route-map LOCAL, so
>  I'm wondering if someone can point me in the direction of a way to
>  accomplish the same thing in a reasonably similar manner.

You're right, JUNOS is unlike IOS with the 'network' statement.

In JUNOS, you 'export' from or 'import' into the routing table.
So you always have to use the policy framework to manipulate
routing information, unlike in IOS where routing policy is
optional ('network' statements can announce routing entries, but
you just miss out on BGP attributes, e.t.c.).

>  I've seen
>  something like this, but is there a Better Way?

In short, JUNOS is super flexible in that it can be as wordy as
it has to be, a little less so, or more. What you need is 
configuration and policy optimization. That comes as you get
more hands-on experience with JUNOS.

> protocols {
>     bgp {
>         group foo {
>             type external;
>             export ANNOUNCE;
>             neighbor 2.2.2.2 {
>                 family inet {
>                     unicast;
>                 }   
>                 peer-as 2;
>             }       
>         }           

> prefix-list local-routes {
>     1.1.1.0/24;
> }

I would recommend using route filters, though. They are more
flexible for what you (and most networks) are really trying to
do. They also cut down on the size of your configuration.

> policy-statement ANNOUNCE {
>     term local-routes {
>         from community LOCAL;
>         then {
>             community delete all;
>             accept;
>         }
>     }
>     term default {
>         then reject;
>     }
> }

You probably want to specify your routing protocol source.
It should work, but I would :-).

In the policy above, anything with a community of '1:790'
will be announced to your eBGP peer. This is less wordy
than IOS :-).

> policy-statement LOCAL {
>     term local-routes {
>         from {
>             prefix-list local-routes;
>         }
>         then {
>             local-preference 790;
>             community add LOCAL;
>             next-hop self;
>             accept;
>         }
>     }
> }

The above bit of the configuration is not relevant to
this query, as you're just dealing with the "ANNOUNCE"
policy-statement (which doesn't reference this in any
way).

However, I think I know what you're trying to drive at. You
might want to consider expanding on your "ANNOUNCE" 
policy-statement and add stanzas that originate the local
prefixes to your eBGP customers, if that is what you're trying
to achieve.

To give you an example - for all our eBGP customers,
all routes announced to them are done so via the use of
a BGP community or set of communities. The only routes
not announced based on community are those locally generated
for customers who have PA space, but don't run BGP. Every
other route source must be a BGP route with a certain community
or set of communities attached to it.

> The Cisco method seems much less wordy than the JunOS equivalent.  Is this
>  JunOS syntax just one way to do this that happens to be a bit on the wordy
>  side, but a simpler (read: less wordy) method does in fact exist?

We like IOS-based route reflectors because knowing how large
their configurations can be, it's easier to wade through
a classic IOS configuration arrangement than it is JUNOS,
although that doesn't speak to other aspects where either
platform may be strong(er) or weak(er).

If only IOS route maps were more intelligent about actually being 
arranged based not only on sequence numbers, but also alphabet. 
But I digress :-).

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20091202/1824c2aa/attachment.bin>