I'm setting configuring new VLANs for VoIP on my core switch and wondered if I will need to configure those VLANs on every trunk port along it's path. Network is L2; wasn't sure if there was an easier way or not or if that was even nessacary.
if the port setup as just trunk not any explicit allowed vlan command, then all the VLAN allowed.
if not you need to allow that VLAN in the path.
Again thinking all the switches are layer 2 and on the Core you have Layer3 (example)
if they are Layer3 deployment on access switch then you do not need to allow in trunk at all.
If you transiting multiple switches, and using trunk links, and want to "span" a VLAN across all the intermediate trunks, you need to insure the VLAN is allowed, which, as noted by @balaji.bandi, all VLANs are allowed, on trunks, by default. But, if you explicitly only allow some VLANs, you'll need to insure you allow the VLANs needed/desired to cross your transit trunks.
What I don't fully recall, is whether transit switches also need to "know" of transit VLANs, beyond being allowed on the trunks. (I recall [???] that they might need to be "known".)
Laugh, well yes, likely the reason that Cisco provides VTP. Personally I like VTP, but many hate it. Basically it's like having matches, very easy to start a fire, which is good if that's what's intended, not so good if that's not what's intended.
Careless use of VTP versions 1 or 2, can easily reset your L2 configs (I've personally seen it happen, in large Enterprise's production, HQ, LAN environment [at least in that case, it wasn't me - laugh]). VTP, version 3, makes it (much) harder to zap your L2 configs by "accident".
With, or without VTP, with L3 switches being so common, and their routing performance, more-or-less the same as their switching performance, when possible, we can design networks with very restrictive L2 domain topologies. Even without L3 at the access/edge of the network, VLANs with access ports can often be restricted to just the access/edge, with a trunk to a L3 distribution which has just the SVIs for those VLANs. I.e. any one VLAN's access ports never extend beyond a single device.
Such, designs though, probably require as much care-and-feeding as L2 networks without VTP, but you avoid many potential L2 issues.
There's VTP v1 on this network. We're upgrading the switches next year to the 9k series and I'm changing this network to L3 then. We're rolling out all new phones here in the next couple of weeks and I have to create all new VLANs for it with Opt 150. I've never had to mess with Opt 150 before and I've never created this many VLANs and had to configure them on so many switches before, so this will def keep me occupied the rest of the week. lol
VTPv1 is much evil compared to the new version, any small mistake as mentioned you fire in the wrong area, the whole thing is gone. (I would be very cautious with VTP and STP - they are good as mentioned as long as you using right way).
first I suggest taking a backup of all the configurations.
understand each device config before you flame it or light it with new config adding.
so you know where you added and what was old config, rather mess up.
make a sure to start with fewer changes and move to the next level once you are confident and network stable.
"Are you saying I can burn down the entire config on the core switch by adding new vlans because I have VTPv1 on there?"
As @balaji.bandi notes in his reply, no, that's not how you burn down your L2 VTP network (again just for versions 1 and 2). (Oh, and BTW, when you burn down a VTP network, it effects ALL the VTP switches in the VTP domain, not just the VTP switch causing the burn down.)
The cause of whole L2 VTP network burndown is adding any VTP switch, that has an incorrect VLAN database with a higher revision number than the VTP network domain is currently running. I.e. the added switch's VLAN database replaces all the other VTP switches database. Also, BTW, the VTP switch being added can do this regardless of whether it's running server or client mode.