[c-nsp] route maps and bgp

[Jon Lewis]

On Wed, 5 Oct 2005, Pete Templin wrote:

>>> BGP communities is the only sane thing to do here.
>>
>>
> There might have been a misunderstanding here - what Alexander wrote is
> correct; if the customer stops announcing the prefix to <you> but you
> are still learning the prefix from <other-provider>, the prefix will
> match the prefix-list and <you> will provide transit from
> <other-provider> to <provider>.  Long story short, using only a prefix
> list means you will err on the side of over-announcing things.

Another simple way to do this safely, avoiding the complexity of 
communities is a combination of prefix-list filters on customer BGP 
sessions, and an as-path filter-list on your transits.

i.e. [abbreviated config to illustrate the point]

router bgp 13473
   network 3.4.5.0 mask 255.255.255.0
   network 6.7.0.0 mask 255.255.240.0
   neighbor w.x.y.z filter-list 1 out
   neighbor w.x.y.z desc transit1
   neighbor 1.2.3.4 filter-list 1 out
   neighbor 1.2.3.4 desc transit2
   neighbor 5.6.7.8 desc customer1
   neighbor 5.6.7.8 prefix-list customer1-routes in
   neighbor 5.6.7.8 remote-as 12345

ip as-path access-list 1 permit ^$
ip as-path access-list 1 permit ^_(12345_)+$

ip prefix-list customer1-routes permit a.b.c.d/24

With this sort of config, you limit (via prefix-lists) your customers to 
announcing "valid" routes to you, and then you limit your advertisements 
to transits by only announcing routes with no as-path (your own routes) 
and routes with as-paths (allowing for customer AS prepends) indicating 
they came directly from your BGP customers.  This is how Atlantic.Net 
worked for several years.  It gets to be a PITA to maintain when you have 
transits and customers spread across multiple routers (having to update 
as-path access-lists in multiple routers).

At some point, I decided I'd had enough of that, and wanted some other 
features communities provided, and converted to accepting routes from 
customers via prefix-lists, marking them with a community string in 
route-map input, and then using route-map output on transits to only 
announce routes with the right community strings to each peer.  The big 
advantage with this is when you add a BGP customer, the only changes 
necessary are on the the router they peer with (just receive and mark 
their routes).  This also makes things like selective prepends possible. 
>From my experience, the big thing to watch out for in this sort of config 
is to strip communtiy strings (set community none) on routes you receive 
from transits as they may already be tagged with strings you're using 
internally.

For someone just getting started with BGP/multihoming, and no BGP 
customers, communities are probably a bit more complexity than they need.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                | 
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________