Is there a good way to programmatically configure VLANs on a managed switch?
My situation is that my company makes a product that (currently) requires the user to set up a dozen or so VLANs on a managed switch that is dedicated to the exclusive use with our product.
Currently, the way it works is this: The user enters his system-configuration preferences into a proprietary (Qt-based) GUI that we provide, and when he's done the GUI spits out a "VLAN configuration report" indicating what VLANs need to be set up, and which Ethernet ports should be members of which VLANs. The user is then responsible for using the switch's Web interface to manually enter those settings into the switch.
This "sort of" works, but requiring the user to enter all of that data is both tedious and error-prone, so we'd like to somehow automate the process: that is, have our program connect to the managed switch directly and tell the switch what VLANs to set up and what ports to assign to them.
What is the best way to do this? Is this something that can be accomplished using SNMP? If so, where do I look to start implementing such a function? (I'm fairly experienced with basic TCP/IP programming, but I don't know where to start with SNMP.)
Solution 1:
RFC2674 might help. This would be a non-trivial implementation, but less vendor specific than other possible solutions. It defines the Q-BRIDGE-MIB which allows for changing VLANs via SNMP.
Solution 2:
EDIT: I came back to this question to rectify a bad situation. For future readers, the idea of a system that needs 12 VLANs is highly likely to be the sign of something terribly wrong. Furthermore, the notion of automatically configuring a client's networking equipment to create those VLANs has an even higher likelihood of being the Wrong Thing.
Thanks to the sleuthing skills of Tom O'Connor, it was discovered that the product that the question's author is dealing with may have a better reason to do this than most. I emphasize the uncertainty in the situation because, regardless of scenario, I believe the overall concept still has grievous fundamental flaws. I am willing to be wrong.
Again I leave a note to future readers: if you want to do this, assume you're doing the Wrong Thing. Ask others for advice. Others who verifiably know more than you about the topic of network management and your scenario. Only programmatically create a dozen VLANs if you and several other professionals (preferably those who are not emotionally or directly professionally tied to the project) all agree that it's the best thing to do.
Having said the above, my original answer picked on the post's author and should have been less informal. For my part in the harassment I offer direct apologies to Jeremy Friesner, the ServerFault community as a whole and I accept wrongdoing. It did not render the community in a good light.
The remainder of the post is left in its ignobility for what it's worth.
My situation is that my company makes a product that (currently) requires the user to set up a dozen or so VLANs on a managed switch, before the product can be used.
Besides the fact that I just threw up in my mouth a little bit...
My question is, what is the best way to do this?
I think you've already done the best you can do. You would need to make some kind of script that can speak to the most common networking devices through their own preferred method. For example: somehow making a script that talks to Cisco devices over SSH or a serial cable and configures the VLANs and is mindful of your clients' own configurations and VLAN numbers and etc. The script would be very complex script and even so, woulds still probably need to be wizard driven to make sure that the proper options are selected. That means lots of time, lots of effort and lots of special cases to take into consideration. In my opinion, you've done your best to give the client a configuration scheme. It's up to them to handle how it's put in place.
If your product needs a dozen VLANs (Madness! SPARTA!), then your clients shouldn't have to be hand-held through making them all. In fact, I'd think they'd want to make sure that the VLANs are tailored to their own systems and not puked out with a script.
Solution 3:
Now that I'm over my initial rage and confusion at the thought of something you'd actually pay for that creates "dozens of VLANs" and wants to automagically destroy configure my switches...
It would be much, much more prudent to just generate some documentation or a network diagram based on values submitted by the customer and the requirements of your product. That way, said customer can assess what real changes that have to be made and plan accordingly.
Creating VLANs willy-nilly in a production environment is an extremely bad thing to want to automate by a 3rd-party that does not have intimate knowledge of the environment.
Even if your code was bulletproof (and with the myriad of versions, vendors, and options, I think this an impossible task), you could completely turf somebody's network inadvertently if the user is inexperienced or perhaps underestimated a change's impact on the network.
Solution 4:
This will vary between switches, but years ago when I was regularly configuring 10s of switches from scratch on a weekly basis, I scripted the whole thing up in Perl with Net::Telnet::Cisco. In modern day, I'd probably go with something like Net::SSH::Perl.
Anything you'd end up typing on the console, you can script.
Solution 5:
Assuming you're using a Cisco Catalyst switch (which, frankly, you should be).. Then there's two options I can think of.
1) Use Net::Telnet::Cisco to tell the switch to dump the config to a tftp server, grab it from there, parse it with something (augeas springs to mind), then squirt a fresh copy back with tftp.
2) This document seems to do what you want. "Add a VLAN to a Cisco Catalyst Switch With SNMP"
I'm not saying it's a good idea, but it is certainly possible
If I were challenged with doing something similar with a web-based switch, you'd probably find me with Fiddler2 looking at the HTTP requests, then doing something dirty with Python's httplib.