|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Managing CE eBGP details & common/accepted CE-facing BGP practices
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) -- Nathan Ward
|