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

Justin Shore justin at justinshore.com
Sun Dec 21 03:01:07 UTC 2008


Suresh Ramasubramanian wrote:
> Heck, you could store all that in Rancid .. even cvs/svn

I should have said it earlier when I mentioned config backups.  I'm 
already a heavy user of RANCID, archiving my configs hourly.  Been using 
it since right around v2.0-2.1 which would be several years ago (feels 
like a lifetime).  So my config backups are more than taken care of. 
What I'm interested in is if I should also document the PE-CE BGP config 
details elsewhere or if I should just leave them in the PE and let my 
backups cover me.

Part of what's driving this is my desire to create a book of templates 
for our assorted product offerings that covers both PEs and CEs. 
Eventually I won't be able to handle everything myself and staff will 
have to be added.  Eventually we'll have to separate operations, 
engineering, security and maybe even install/turnup tasks.  I'd like 
there to be a solid practices established and documented in a solutions 
bible of sorts before that happens.  My brain can only store so much 
info and I can only do so much in a day.  Plus having all these details 
ironed out sooner rather than later, and documented, will help keep me 
honest (ie, no band-aides that I plan on removing when I get time <g>). 
  The other added benefit is that as I figure out how to do something 
rather fancy or in a simple and elegant manner I can document it for my 
own benefit and others.

So back to the original topics, does anyone have suggestions for 
CE-facing BGP config or the management and documentation of the CE 
details?  I'm experimenting with peer-policy and peer-session templates 
right now.  I'm sure with dozens or hundreds of peers their benefits 
would be more evident.  So far they only seem to reduce my default-only 
test peers by 3 lines of config each.  I'm sure this would be more saved 
lines of config if I was doing something more fancy.

Thanks for the input
  Justin





More information about the NANOG mailing list