[j-nsp] BGP origination

[Peter van Oene]

At 12:13 PM 2/1/2003 +0100, Gert Doering wrote:
>Hi,
>
>On Wed, Jan 29, 2003 at 08:10:37AM -0500, Richard A Steenbergen wrote:
> > You miss my point. Say a customer comes to you with their own /24, but
> > they don't speak BGP (it happens). You have to announce it for them, and
> > put it on an interface for them. If you want to use a static route for a
> > holddown, you're either gonna be putting it on the interface as 2 /25s, or
> > bust.
>
>The latter is actually what we do in the "customer PI case".  Put a /24
>as a static null route into our routers, and redistribute that to BGP.
>In the IGP, the customer route is routed as two /25s - which has the
>advantage that tricks like dial-backup work just as easily as for PA
>customers, and still any internal instability won't affect the BGP
>advertisement.

I personally try to do everything in my power to keep customer routes out 
of my IGP.  The above method works, but tends to break that rule.  In the 
cases where one cannot do as dre recommends, which is to allocate a 
/31(/30) for the dmz link, then I would prefer to redistribute direct into 
BGP using prefix lists to clarify and then actions to assign communities as 
many have noted.  Even in the case where you have different classes of 
routes to be redistributed, you could easily use a multi-term direct-to-bgp 
policy that matches various prefixes lists and assigns different 
communities respectively.  In this case, you get very simply provisioning 
in that direct-to-bgp stays the same, and one simply needs to populate a 
prefix list within the provisioning steps, and you keep your IGP 
clean.  Further, this actually leads to less config bloat that per route 
communities.

If you have the case where each route needs very different sets of 
communities, you might be working with a very unscalable community set 
which could benefit from some tweaks :-)

Pete



>It's a bit ugly for troubleshooting, though.
>
>gert
>--
>Gert Doering
>Mobile communications ... right now writing from * Braunschweig *
>_______________________________________________
>juniper-nsp mailing list juniper-nsp at puck.nether.net
>http://puck.nether.net/mailman/listinfo/juniper-nsp