[c-nsp] BGP question : What's the best way for filtering outgoingprefixes?
Scott Granados
scott at granados-llc.net
Thu Aug 18 17:38:16 EDT 2011
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/
More information about the cisco-nsp
mailing list