Managing CE eBGP details & common/accepted CE-facing BGP practices

Nathan Ward nanog at daork.net
Mon Dec 22 10:27:01 UTC 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)

--
Nathan Ward	








More information about the NANOG mailing list