I must first comment and say that this is an excellent tool. I am a network admin of many years and I really like it and appreciate the work that has gone into it.
I must also note that I am not a code person, and neither am I a SQL expert, nor am I a PHP expert, but I am only just a user.
I do share the same thoughts with other users in this forum topic that a set of VLAN features should be included in the schema. Specifically, I recommend:
1. VLAN tracking. The ability to track parse a VLAN section with VLAN data, including VLAN ID's, descriptions, locations, the subnets assigned under that VLAN. Ability to search by VLAN ID's or vlan descriptions and so on.
2. Relational functions to support VLAN information populating into the subnet sections.
Or, simply integrating a column or a table that can relate the vlan data with the subnetwork data.
It's nice to keep all of this data in a single database; many organizations have separate means of tracking VLAN data, and IP address data, and often times, one or the other DOESN'T get updated.
It would be nice to have a single tool to manage both pieces, and set controls or safeguards against overlapping subnetworks and/or VLAN ID's or vice versa (i.e. That subnetwork is already assigned to VLAN 2/descrBUILDING1/ by david/3/10/2010).
It would be even COOLER to provide a hierarchical means of assigning VLAN ID's (whether duplicate or not) to other buildings or some other hierarchical tree. For example, VLAN2 could be assigned to BUILDING-A for and then VLAN2 could also be assigned under BUILDING-B for If an IP admin wanted to create a new VLAN2 at "building-B" the system should safeguard and warn him or her that VLAN2 already exists at "building-b" for subnet But, if he/she wanted to create "VLAN2" and "building-C" for, it would allow the assignment and require the user to also create the subnet information.
Also, a non-subnet, or non-addressed vlan option should also be available. Some network administrators will create isolated, layer2 only VLAN's on their bridged domains to allow partners or vendors operate in an isolated fashion. In a case such as this, the network admin DIDN'T assign any IP addressing to that VLAN/broadcast domain, but has left it up to the partner to do so. The VLAN is isolate from the rest of the network, it doesn't have ANY routing gateway assigned to it, and in other plain English terms, it's a "dead end vlan" AKA a "chrooted" vlan in which there is no exit into the rest of the network - again, no layer3 operation into the rest of the network. The vlan/network is truly isolated. Sometimes, server admins like to have these kinds of networks/vlans for back-end functions or HA hearbeats and so on. Still, nonetheless, even though there is no IP addressing assigned by the network admin, there should still be a way for the network admin to track the vlan info in the same database as to avoid duplication and have other safeguards.
Often times, I find people assigning VLAN ID's, and forgetting to put the subnet in the IP database, or vice-versa. It would be slick to have a single tool that would manage both in one database and safeguard overlap and duplication.
Anyway, surely I am asking for the world, so forgive me - I am a user! But, it would be very cool so have some vlan features - please consider this on your next serious code-rework.
Thanks for this great tool! I love it!


  • David

    David - 2010-03-07
    • priority: 5 --> 3
  • David

    David - 2010-03-07
    • priority: 3 --> 2

Log in to post a comment.