Does anyone have a recommendation of any software products either commercial or freeware which will import the ip routing table from one of my routers/switches and display it in a sorted manner? We just need an easier distributed method than logging into our Black Diamond and typing sh iproute sorted every time we need to find an available subnet.
Thanks in advance for any advice you can offer.
Andrew
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.9.0/852 - Release Date: 6/17/2007 8:23 AM
I'd configure a 'nix host running openbgpd[1] as a BGP peer. This
approach works great for periodic dumps and offline analysis of your
routing table.
I'll refrain from commenting on the wisdom in walking your RIB as a
_means_ of address assignment (and not merely a safeguard), so as to
avoid steering this discussion off-topic. 
-a
[1] <http://www.openbgpd.org/>
Drew Weaver wrote:
Does anyone have a recommendation of any software products either commercial or freeware which will import the ip routing table from one of my routers/switches and display it in a sorted manner? We just need an easier distributed method than logging into our Black Diamond and typing sh iproute sorted every time we need to find an available subnet.
Wow, LOL!
The software product is called a "text editor".
Look at your list of assignments in your NS .arpa. file:
1) Find a subnet that hasn't been assigned.
2) Update the text file.
3) Wait for it to propagate.
4) Tell the customer.
The concomitant procedure for static host assignment is:
1) Find a number that hasn't been assigned.
2) Update the text file.
3) Wait for it to propagate.
4) Then, and only then, update the forward NS file(s).
5) Tell the customer.
Of course, there is software that will automatically maintain the files,
and even send a signal to bind, but I've alway found them to be weak at
subnet management. Text editor is the way to go -- using subversion for
"distributed" file management (that is, knowing who to blame for mangling
the assignment commit).
In words of Vijay, "It does not scale".
In words of Randy, "I encourage my competitors to do this".
Neither 'show ip route' or 'have a text file' scale beyond a hundred
customers.
Proper IP management is complicated. You want to have following things:
a) easy IP allocation
b) IP association with customer and specific service for following
purposes:
* future IP justification with RIR's
* abuse trackback
c) easy IP deallocation when customer leaves
d) minimizing additional fragmentation of blocks - for example, if you
need a /29 and you have a /29 and a /28 available - you want to take /29
before fragmenting /28.
e) support for 'special-purpose blocks' - ie, /30 for pt-pt and
/32 for loopbacks are to be assigned from blocks that are not used for any
other purpose.
f) (similar to above) regional/local allocations: "give me a /32 out of
dallas loopback blocks"
g) two-way sync (or at least diff) of your databases to operational data
(the configs in routers) - so you can see what it *should* be vs what it
actually is. Ideally, generate commands to update configs to the
database.
I think everyone ends up writing their own systems to manage IP space as
part of general network management. Unfortunately, they end up being very
specific to the network in question (for example, my stuff is very geared
toward terminating a large number of vlans on a l3 switches, etc)...
William Allen Simpson wrote:
Drew Weaver wrote:
Does anyone have a recommendation of any software products either commercial or freeware which will import the ip routing table from one of my routers/switches and display it in a sorted manner? We just need an easier distributed method than logging into our Black Diamond and typing sh iproute sorted every time we need to find an available subnet.
Wow, LOL!
The software product is called a "text editor".
Look at your list of assignments in your NS .arpa. file:
1) Find a subnet that hasn't been assigned.
2) Update the text file.
3) Wait for it to propagate.
4) Tell the customer.
The concomitant procedure for static host assignment is:
1) Find a number that hasn't been assigned.
2) Update the text file.
3) Wait for it to propagate.
4) Then, and only then, update the forward NS file(s).
5) Tell the customer.
Of course, there is software that will automatically maintain the files,
and even send a signal to bind, but I've alway found them to be weak at
subnet management. Text editor is the way to go -- using subversion for
"distributed" file management (that is, knowing who to blame for mangling
the assignment commit).
However Drew suffers because some idiots in his org fail to update the files correctly. I used to have the same problem when I took over ops at a small ISP. They were using the routing table to store assigned subnets trick. It was OK until a link died so a subnet dropped out of the routing table. They thought "Oh look spare space" and assigned it to somebody else.....
There are also a load of decent (not good) free IP address management systems available, some with built in DNS updaters.
I do not use these because they all drove me mad. Now I just have somebody else do it for me. It's worth it 
It is very much an internal system, designed to meet our needs, as such it
is tightly integrated with the rest of the systems - billing, customer
management, network mapping, etc.
I've been giving some thought to cleaning it up and releasing it under
some sort of a public license in hope it'll be useful to someone, but
unfortunately hasn't found time yet 
I think realistically, even if you have full source, it'll be good for the
ideas how to do things, it will be *very hard* to separate the IP
management out of everything else.
(IP management is maybe few hundred lines of perl pl/pgsql code total)
hth
-alex
alex@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.
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!
> 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
Carnegie Mellon's NetReg <http://www.net.cmu.edu/netreg> (*) is an open source system that provides a pretty complete IP Address Management toolset, including management of DNS & DHCP configurations for ISC bind/dhcpd. We manage DNS & DHCP for 50K machines, and NetReg does it all. It is available under an OSS license and is in use at several other locations. NetReg provides a self service web interface with flexible permissions, privilege delegation, IP address space management, DNS record validation, and more.
As the current primary developer of the system I'm a bit biased, but I think its a great system. It has a steep learning curve, and the documentation leaves something to be desired (like a tech writer...), but once you hit a certain scale the benefits outway the cost. On our site you'll find several screen shots and a working demo with some base data you can experiment with, but obviously the full power of the system isn't utilized until you have lots of data and can see the resulting zones & config files.
There is an active mailing list, feel free to join it and ask questions.
*: Not to be confused with Southwestern University's NetReg, which is a completely different system developed in parallel around the same time.
-David Nolan
Network Software Designer
Computing Services
Carnegie Mellon University
You've never used comments in your dns? I have yet to figure out how to insert a comment into my routing tables that tells me what a routing entry is for, but it's pretty easy to put a # line in my tinydns data or my bind zone file that tells me who this is for, how large it is, when it was allocated, by whom, and when it was deallocated and why....
After all, there are occasions when an allocated subnet won't show up in my routing tables....
alex@pilosoft.com wrote:
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.
Others have mentioned this, but that's just wrong. For 20 years, there's a
reason we've been using policy-based routing, routing arbiters, etc.
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.
Others have mentioned this, but of course all that should be stored as
comments in the file. I never found any automated tool that stored all
the information properly. Text records with comments are flexible.
And the allocation size is extremely important, as you need pointer records
to the customers' .arpa NS records! Surely, you don't handle everything on
8-bit boundaries in this day and age....
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.
There's a saying where I grew up:
Ford is in the business of making cars.
GM is in the business of making money.
The notion is that GM doesn't really care about the quality of its cars,
as long as it makes money. Branding the local congresscritter "the
representative from GM" is not a compliment. (Not so coincidentally, his
considerably younger trophy wife is a GM heiress.)
The 'net is what I've spent most of my adult life making. 'nuff said.