Easily deploying new VLANs in a large environment

Here is a really basic script template in Perl for telneting into a list of devices (one on each line in a file called devicelist.txt) and configuring some commands. Depending on exactly what you are doing it should provide a good start.

  use Net::Telnet::Cisco;

    # read in a list of devices
    my @devicelist;
    open(DATA, "<devicelist.txt") || die "Can't open file!";
    while (<DATA>) {
            chomp;
            push( @devicelist, $_);
    }

    # loop through the devices
    foreach $hostname (@devicelist)
    {
            # telnet to device
            my $cs = Net::Telnet::Cisco->new(Host => $hostname);

            # login, go enable, disable paging, go into config mode
            $cs->login( "username", "password" );
            $cs->enable( "enable_password" );
            $cs->cmd( 'terminal length 0' );
            $cs->cmd( 'config t' );

            # configure the device
            $cs->cmd( 'vlan 100, 200, 300' );
            $cs->cmd( 'interface Ethernet0' );
            $cs->cmd( ' switchport access vlan 100' );

            # exit config mode and write the config
            $cs->cmd( 'end' );
            $cs->cmd( 'wr mem' );

            # close the connection
            $cs->close;
    }

Here are some more details on Net::Telnet::Cisco as well.

I would say you have a couple of options:

1. Manually. Takes most time. Safest? Depends on the one doing the config.
2. Use some tool like Kiwi Cattools or Rancid etc. Much easier but you would need some kind of logic to check if VLAN is already existing or you could mess up the naming structure. Maybe not a huge deal?
3. Script it! Use Perl, Python, Ruby or whatever language you have experience with. Takes some time to build it but once it done you could reuse script for other configuration tasks. It would be customizable but it depends on if you are comfortable coding.
4. Use SNMP. Never tried this. Would require RW on the devices and I don't really like running RW on my network devices.

Configuration management software might be worth looking into -- Puppet's network device management can add vlans easily to numerous Cisco devices (if you're using Cisco).

The challenge you now face is that you are going into a mixed environment. You mention you are moving towards Juniper from I assume Cisco? In a pure Cisco environment VTP v3 with passwords would be the way to go and supports over 4k vlans. In the Juniper world the equivalent would be GVRP.

You may be able to use some form of centralized management such as Puppet as was mentioned by Shane Madden, SolarWinds, HP OpenView and such but you will still have two scripts to manage.

I would try to keep things as simple as possible (KISS) for now as you transition from one vendor to another. Using VTP and GVRP on the appropriate hardware is probably the way to go and doesn't add the potential cost for other solutions or complexity of managing another new thing.

Solarwind's Network Configuration Manager can run scripts in IOS devices and some others.

It also does things like nightly config backups, change reports and config audits. Their pricing isn't horrible but they're merging NCM with their Orion Network Performance Monitor and I'm not certain you can run NCM separately any more.

It could be that VTP is your answer. Like any "automated" tool, it has it's risks, but you can mitigate them with proper planning. You should also do some reading to make sure you understand how it works or you can inadvertently create your own problems (again, just like any automated tool).

I would recommend VTP version 3, as this can help protect from some of the potential problems and provides additional benefits.

You can easily find hundreds of documents by searching "vtp version 3 configuration" in your search engine of choice.

It sounds like you have a collapsed core. Is that correct?

One way of dealing with too many changes based on adding new VLANs' is to move your L3 boundary closer to the access. It requires some work up-front, but if your design is well planned, and thought out, it should make adding new VLAN's a one to three device task (depending on whether L3 stops at Distribution or Access layers).

There are a bunch of other benefits you get from that as well, including faster convergence in the event of a lost link.

I use ruby with the net-scp and net-ssh gems to automate tasks with our network equipment. It's a pretty short script to execute commands (excerpt, not a finished product):

begin
    Net::SSH.start(fqdn, username, :password => loginPassword) do |session|
        output = ""

        channel = session.open_channel do |ch|
            ch.send_channel_request "shell"
            ch.on_data do |ch, data|
                output += data
            end

            ch.send_data "conf t\n\r"
            #Some tasks here
            ch.send_data "exit\n\r" #Exit config mode
            ch.send_data "exit\n\r" #Exit device

        end

        # Wait for everything to complete
        channel.wait
    end
rescue Exception=>e
    errorOutput = fqdn + ": " + e.to_s
    puts errorOutput
    puts output
    return device
end
return output

Keep in mind that you should have a blank loginPassword variable. If blank, it will use your RSA public key for login (supported on HP ProCurve and Cisco 15.X platforms).

Using something like git and a few short scripts, you can organize all your equipment configurations with diffs of changes and who made the changes (assuming your engineers pull configs and commit them after work is completed).

Also it should go without saying, but just in case, always test scripted work in a lab before running on production equipment. Especially when executing commands and changing configurations. Test, test, test.