[c-nsp] BGP question : What's the best way for filtering outgoing prefixes?

[Keegan Holley]

On Aug 19, 2011, at 11:25 AM, Jay Nakamura <zeusdadog at gmail.com> wrote:

> While testing, I am wondering, is it standard practice to clear my
> community strings from routes before going to peer/transit?
> 
> 
> 
> On Thu, Aug 18, 2011 at 4:00 PM, Jay Nakamura <zeusdadog at gmail.com> wrote:
>> This is a bit complicated.  Let's say we are provider X.  X is
>> connected to transit provider A and B.  X currently uses prefix-list
>> to filter outgoing BGP announcement.
>> 
>> We are now getting a customer that wants to multi-home, so their
>> transit provider is X and C.  We gave them a /24 from our block, let's
>> call it IP1.
>> 
>> I was simulating how I should configure our routers so it was secure
>> and did all the right things when I noticed IP1 route coming in from
>> provider A is getting advertised to provider B through us.  It makes
>> sense since it passes our outgoing prefix list.  (So, AS path was
>> "AS_X AS_A AS_Customer" into provider B)
>> 
>> What's the best way to prevent this?  Here are the two options I was
>> thinking of doing
>> 
>> Option 1
>> Set all routes learned from A and B with unique community, and filter
>> out any routes with that community for outgoing routes to A and B.
>> 
>> Option 2
>> Filter on AS-Path for routes going out A and B with
>> <AS-X>$
>> <AS-X>_(<AS_CUSTOMER>)+_$
>> (I think, I haven't looked closely at AS path syntax)
>> 
>> With Option 1, I don't have to do anything when we add another BGP
>> customer but not sure what the overhead of tagging all routes coming
>> in with community is.  With Option 2, I have to edit the AS-path every
>> time we add a customer.
>> 
>> Is there a better option?
>> 
> 
You could track your RR space and filter the aggregates orlonger.  Option 1 requires others to transit your communities which they may not.  Option 2 requires you to constantly update prefix lists as customers come and go.  Today junk could be tomorrow's paid transit if a certain customer leaves.  The only hole is RR space assigned owned by customers would have to be tracked individually which can get cumbersome.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>