Software or PHP/PERL scripts for simple network management?

alex at pilosoft.com alex at pilosoft.com
Wed Jun 20 02:59:09 UTC 2007


On Tue, 19 Jun 2007, William Allen Simpson wrote:

> 
> alex at pilosoft.com wrote:
> > Neither 'show ip route' or 'have a text file' scale beyond a hundred 
> > customers. 
> > 
> Hogwash.  Used text file allocation for ~3,000 customers.  After all, it
> is *REQUIRED* to exist (for bind).  You need *a* canonical place that is
> authoritative for all others.  Existing tools easily track commits.
> 
> DNS should always reflect reality.  Then automated tools will show human
> readable information.  Someday, it may even be authenticated (but I've
> been beating that horse for a decade).  I'm sick and tired of bad NS
> data.
I agree, DNS should *reflect* reality, but I think it is very much 
misguided to say that DNS should be the place to have canonical 
information (i.e. source of all data). Canonical data is in 
routing/forwarding tables on routers/switches. That's the operational 
reality.

The amount of data that you need to track IP allocations just doesn't fit
well into DNS - there's no place to store customer id/service id, the
length of allocation (is this IP part of a /28? /29?), etc. So you'll have
to have "canonical data" somewhere else anyway.

> Yes, we used a separate database for billing, and maybe could have
> automatically generated the text file.  Didn't want the customer
> service/billing folks to have access to network configuration.... ;-)
> 
> Any time you have more than a single location for maintaining network
> configuration data, or allow technicians to just slap a route into a
> router on a whim, you are bound for future difficulties!
> 
> And when the routing table doesn't match, withdraw the route, and fire
> the miscreant that failed to properly maintain the allocation data!
Unfortunately, I'll have to say again that this doesn't scale. :)

-alex




More information about the NANOG mailing list