Managing CE eBGP details & common/accepted CE-facing BGP practices
nanog at daork.net
Mon Dec 22 04:27:01 CST 2008
On 21/12/2008, at 2:22 PM, Justin Shore wrote:
> While I'm sure this could be easily stored in a spreadsheet
I think the best piece of advice I ever saw RE network management, is
teach your network ops people basic SQL. Spreadsheets work OK for one-
off calculations, use SQL for any sort of data storage. This is a
perfect example of where that would be useful.
> What are common and accepted CE-facing BGP practices? MD5 AUTH,
> GTSM, max prefix limits? Which is preferred, route-maps or prefix-
> lists for controlling advertised and/or received routes? Do any SPs
> utilize AS-Path ACLs to check that prefixes from an customer's ASN
> are claimed to originate from there? Are there any SPs out there
> offering BFD support for BGP or CE-facing peering sessions?
My recommendation here, when talking about incoming advertisements
from customers is to use prefix lists *and* route-maps.
Use prefix lists for an overall accept/reject.
Use route-maps to tag received prefixes with communities. Use these
communities on your border/peering routers to control advertisements.
This way, you make your border/peering routers low-touch - adding a
new customer prefix only needs to be done on the customer edge, and
that can be done by your provisioning guys leaving your more
"important" routers to only be touched by people who *really* know
what they're doing, in theory.
Having some well known communities to allow your customers to control
their advertisements would be nice as well - to encourage you to
prefer/not prefer, and also control how you advertise their prefixes
outside your network.
Have a read after "Communities accepted from customers" in the RADB
WHOIS for AS3356 for a fairly comprehensive example. Other's might
have better examples, but I've often used this one as being pretty good.
(whois -h whois.radb.net AS3356)
More information about the NANOG