Ether channel.

[weasleman]

So i am guessing that VTP v3 is enabled by default with the new IOS or do you have to enable it some how. Just curious.

The VTP makes sense thats why i use it i dont want to create vlan 100 with name on 5 different switches.

Is there a reason why you said VTP gives you problems ? curious what these are ?

[NetworkGroover]

there's nothing wrong with VTPv3. It fixes everything wrong with v2 and is sane. But people are so burned by old school horror stories they often still refuse to deploy it.

Only the primary server can change the vlan database, and you need to manually use a force command to take over the primary role, so basically that's all the issues of v2 fixed.

I know what VTPv3 is, and I still don't recommend it. In this day and age, if you're going to automate deployment of VLANs across your environment, take the extra steps and automate more (i.e. just use Ansible, etc.).  The sooner you can get off the proprietary teet - the better.  Why add any complexity (big or small) if it's only going to solve one small part of the provisioning problem when you can solve that and more with something else?

[deanwebb]

I find it rather delicious to have a vendor argue for a vendor-neutral environment, as it then makes it easier for that vendor to replace another.

Thing is, if VTPv3 makes things easy and works and we have all Cisco stuff anyway, just use it. But get a Linux scripting box to do the automation, not Prime. Prime can't even check IOS version, which is a pain for those of us that want to use SNMP to monitor access ports. 12.2(35) and earlier uses different code on the switchport that 12.2(55) and later changes. Prime does not help me *at all* there, and that's just one example why it's not the automation solution you're looking for.

And, if you've got that Linux box scripting things for you, then it makes it easier and more possible to cut over to other vendors and to use methods other than VTPv3 to provision VLANs.

[NetworkGroover]

I find it rather delicious to have a vendor argue for a vendor-neutral environment, as it then makes it easier for that vendor to replace another.

Thing is, if VTPv3 makes things easy and works and we have all Cisco stuff anyway, just use it. But get a Linux scripting box to do the automation, not Prime. Prime can't even check IOS version, which is a pain for those of us that want to use SNMP to monitor access ports. 12.2(35) and earlier uses different code on the switchport that 12.2(55) and later changes. Prime does not help me *at all* there, and that's just one example why it's not the automation solution you're looking for.

And, if you've got that Linux box scripting things for you, then it makes it easier and more possible to cut over to other vendors and to use methods other than VTPv3 to provision VLANs.

Oh, sure, because the rest of the network world hasn't been saying this for years.  It MUST be because I'm a *vendor* who has ulterior motives.  In case you haven't looked outside of your shop, said vendor hasn't really needed to make that argument - it's already been out there and why certain legacy vendors who can't keep up are getting replaced. But I digress.

It has nothing to do with me being a vendor - it has everything to do with knowing the world outside of what a certain vendor says it should be - and working with customers who are solving these problems today.  I don't care what vendor it is - why on earth would you settle for just provisioning VLANs when you can get off your arse and put forward some effort to automate way more than that, for free (Unless you want to take advantage of the spiffy Tower capabilities which most do), with a solution that can not only provision switches/routers but servers, firewalls, load balancers, etc., that can integrate with something like Jenkins to provide workflow automation and checkpoints.  Don't take my word for it - talk to other people out there that do it today with or without a certain vendor's gear - it's a no-brainer.  I mean, I'm lazy, but at the same time if I were in your shoes, the first thing I would be doing as a network/system/whatever admin outside of the daily firefight is figuring out how to automate things which will take some "capex" of time on my part, but I know in the end it will heavily reduce the "opex" of my time, so-to-speak, AND make me more valuable to the company I'm working for, and any future companies I work for after having gained the experience.  I did this as a desktop support guy over ten years ago and figured out how to create an imaging solution using a combination of Acronis (Not even the expensive corporate version) and Windows Sysprep that allowed me to apply a corporate standard image to any desktop or laptop - regardless of hardware - back before you had the expensive solutions there are today to accomplish the same.  This saved the company money and we got to a point where everyone kept all of their data on network storage so if there was a problem that took longer than 5 minutes to fix, we'd just wipe their box and start over - again saving time.  It's glorious when you finally achieve it - it's worth the hours and hours you pour into it initially. We had an IT team of 3 support a corp office and 17 branch offices. I handled help desk, asset management (figured out how to improve this too by learning and creating an Access database instead of the Excel spreadsheet they were doing it on previously), administered the company's volume licensing, did 100% of the imaging, and even some Sharepoint.  You can't do all of that by not finding ways to streamline/improve processes and sticking to the crap ways you've been doing things the previous years.

Like, here's an example, and yes I'm going to use who I work for.  Let's say I go to a dev meeting, and I say, "Hey, let's implement a feature where a switch acts as a server, and provisions VLANs for other switches.  No - that's it, that's all it does".  Do you know how hard that would get laughed at?  That feature was valuable back when we didn't have the automation tools we have today - now, it's not even worth a developer's time.  I would be very surprised if you ever see it or something like it from another vendor down the road (unless they have no other way to automate) again.  I would almost be willing to bet you that if Cisco didn't already have it, they wouldn't develop it today.  That being said, I feel like you should prepare to work in any environment and avoid things like VTP, EIGRP, etc. if you can and there are other solutions widely-accepted by the community at-large.  I didn't even use EIGRP when I was a Cisco fanboy and it's all I knew - we used OSPF and BGP - why?  Because we knew we could possibly have other vendors in the mix and didn't want to have to deal with redistribution just to support running EIGRP in part of our environment - we saw it for what it was.  I mean, EIGRP is so awesome that there are huge, dedicated sections to it in the CCIE R&S material, right?  The answer is no if you don't know (Unless things have changed since I last looked).

And if you find my post a little abrasive, sorry not sorry. It's a vendor-neutral topic and I don't understand why you'd argue to just go the lazy route which gives you less in the big picture.  Like, you literally just said to use VTP cause it's easy, but then automate using a "linux scripting box" - do you understand how conflicting that is?

There's my pompous, vendor-biased view.  /rolleyes I know I'm probably wasting my breath, but it's off my chest.

[deanwebb]

Don't worry, mate, I was just winding you up with my first comment. I meant no wrong with it.

You really are quite right in your comments that going with vendor-neutral solutions really is the best way to do things precisely because of the interoperability and flexibility that they offer up.

There are times, though, when architects lose focus and begin to dictate tools and technologies instead of what they're supposed to do, which is to define services. Too often, architects say, "We'll use this to do that, now go implement it" instead of, "We want these three things: find the product that does them best and send the bill of materials to the project manager."

Then there are vendors that like to show how "It's a SNAP to set up!!!" :cough:cisco:cough:



It's only ever a snap to set up in the demo, unless you've done some heavy lifting up front to get everything to run smoothly. Like you said, put in the effort to get your scripting done right and then you'll have plenty of time for relaxation later. Relax now as you pump out those snappy setups, not only do you find stuff that makes the setup unsnappy, there's other scalability issues later on.

[NetworkGroover]

Don't worry, mate, I was just winding you up with my first comment. I meant no wrong with it.

Mission accomplished.

#Triggered 

[NetworkGroover]

Then there are vendors that like to show how "It's a SNAP to set up!!!" :cough:cisco:cough:

Yeah it seems all vendors do this to varying degrees... that's what I don't enjoy about the sales aspect and why I try to keep myself wrapped up in actual engineering work than doing a bunch of pre-sales type of work.  Unfortunately though the writing is on the wall that a certain vendor is going to be getting too big to maintain the "One SE does it all" model and they're going to have to break out into pre- and post- sales at some point... honestly hopefully I can land in the latter.