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

Danny Thomas d.thomas at its.uq.edu.au
Sun Dec 21 15:47:23 CST 2008


Suresh Ramasubramanian wrote:
> On Sun, Dec 21, 2008 at 8:31 AM, Justin Shore <justin at justinshore.com> wrote:
>
>   
>> 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.
>>     
>
> Sounds like a job for svn with a web based frontend to track configs.
>   

we've been using rancid for years and the configs are used by many scripts
  * rancid modified to no longer remove the lines at the top of "sh run"
     to identify times config and NVRAM last updated and send email
     if the NVRAM is substantially older than running config
  * ip-helpers are compared against our dhcp config
  * subnets, routers, vlans, gateway and hsrp addresses are compared
     against our  database of network information
  * the configs are analysed by a script to identify items not matching
     our config standard; ideally configs would be generated from templates
     but I'm not in a position to make that happen
  * routed address-space is compared against reverse dns
  * when we had border bogon filtering, those ACLs and null-routes
     were compared against a freshly-downloaded aggregated bogon list

one of the problems with rancid is that the code makes it hard to do
other things, e.g. compare the active and standby configs in our 6500s

I'd also like to add a feature that recognizes the significant blocks in 
a config
and store in a database so you can do queries like "when was vlan777 
modified"

Danny




More information about the NANOG mailing list