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

[Scott Granados]

Go with option A, community tags are your friend.  It also removes the need 
for any network statements in your config thus reducing the work in the long 
term.

Something like this


ip prefix-list customer-prefixes seq 5 permit a.b.c.d/19


ip prefix-list not-to-specific seq 5 permit 0.0.0.0/0 le 24

ip bgp community new-format
ip community 1 permit as:1
ip community 15 permit as:115
ip community 15 deny as:1
ip community 15 deny as:666

ip community 66 perm 15
(and 1 and any other communities you define.
Your other community tags are variations on this theme with the appropriate 
as:xxx deny or permit statements to match the effect you want.

Then

route-map customer-in permit 10
match ip address prefix-list customer-prefixes
set community as:115

route-map full-routes permit 10
match community 66

route-map transit-out permit 10
match community 15

route-map transit-in permit 10
match ip address perfix-list not-to-specific
set community as:666


neighbor a.b.c.d remote (customer as)
neighbor a.b.c.d desc customer peer
neighbor a.b.c.d route-map full-routes out
neighbor a.b.c.d route-map customer-in in

or
neighbor e.f.g.h remote-as (upstream as)
neighbor e.f.g.h desc transit-example
neighbor e.f.g.h route-map transit-out out
neighbor e.f.g.h route-map transit-in in

and more as you want more functionality.

community 1 for example could be set to prepend once, 2 for twice and 3 for 
3 times and your customer can tag accordingly.  You could set 120 to 
increase pref to 120 and on and on you get the theme.

This is an over simplified example for the purposes of discussion but the 
end result is that you can control everything with assigning the right tag 
to a learned route and have it distribute across your network and upstreams 
as you want with out having to edit lots of various entries.  You can also 
use peer groups to reduce this further and say tag learned peers as 
community as:112, anounce out your community 15 stuff and insure that 
customers receive peers which you can also tag at a different pref and 
upstreams don't.

Hopefully that makes sense.

Thanks
Scott

P.S. Sorry for any minor errors in format, I'm writing this while riding in 
the back of the car on the way home from work, might drop / add a letter 
here and there but you should be able to get the point.



-----Original Message----- 
From: Jay Nakamura
Sent: Thursday, August 18, 2011 4:00 PM
To: cisco-nsp
Subject: [c-nsp] BGP question : What's the best way for filtering 
outgoingprefixes?

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?
_______________________________________________
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/