> 3) Don't advertise one transit provider's routes to another. Each should
> be filtering your routes, but you never know. Come up with, and use
> BGP communities to control route propagation. As you grow, it sucks
> having to update prefix-list filters in multiple places every time
> something changes...like a new customer with their own IPs.
To reiterate all this, FILTER EVERYTHING.
To start with, explicitly specify in a route-map or similar everything
you want to advertise. I usually create a separate route-map for each
transit/peer and include what I want to advertise via prefix lists (for
my IP space) and/or communities (for downstream BGP-speaking customers
if anticipated).
I think a related *principle* is: "Build everything as though you are
expecting to scale."
This doesn't mean "spend lots of money to buy huge
[routers|servers|commercial software|<etc>], but rather "when you plan
your addressing structure and routing policies and monitoring and
device config generation and... keep the in mind the question "If this
suddenly takes off, and I hire N more people to run this, can I
explain to them how it works? Do I have documentation I can point them
at or is it stuck in my head / on the devices? If I need to add
another M customers in the next month, can I do that easily?".
This is related to the FILTER EVERYTHING -- when you turn up a new
customer / peer / transit / whatever, you shouldn't be sitting around
trying to figure out how you will write their route-map /
policy-options -- this leads to weird one-offs, and quick hacks.
Instead you should have policies already largely designed and simply
plug in their prefixes (or, better yet, use bgpq3 or similar to build
and populate these). Obviously there will be some cases where a new
connection does require some special handling, but that *should* just
be a plugin/chain in an existing policy-statement. Related to this is
how you end up naming things -- I recently found 9 variants of
firewall-filters which basically do:
filter ACCEPT {
term ACCEPT {
then accept;
}
}
named things like: ACCEPT, ACEPT, Accept, Allow, Permit_all,
AcceptAll, dontdrop [0].
Obviously, there is a tension in the "design for scale" - while it
would be great to design a complete automation system so that
everything from installing a new customer to a new sites is simply
typing 'make <thing>' and having everything pull from a database, at
some point you will need to actually build a network, or you'll never
have customers 
Just keep in mind that "Am I building myself into a
corner here?". E.g it only takes 10 or 15 minutes to install something
like NetBox to keep track of addresses (and prefixes and racks and
connections and ...) -- stuffing this in a spreadsheet might save you
a few minutes *now*, but will this scale? Can $new_person easily
figure it out?
W
[0]: My personal favorite is:
filter Accept_All {
term Accept {
then {
count dropped;
reject;
}
}
term filter_<customer> {
from {
prefix-list {
<customer>;
}
}
then accept;
}
term NEXT {
then log;
}
}
Presumably this all made sense to <name_removed_to_protect_inoccent>
when they stuck it in at 3AM to deal with some crazy issue, but...
