cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
926
Views
0
Helpful
11
Replies

Need advice and help on VLANS and vtp on large bridged network

tedmittelstaedt
Level 1
Level 1

Hi All,

 

I have a customer with a meshed WAN of 7 sites, with Cat 2950's at each sites and multiple VLANS.  6 sites are "remotes" one site is "master" and that site has a 3900 series.

 

The problem is all the VLANS do not all appear in all sites.   There is a routed network superimposed on this but that's not important to the discussion other than to say the uneven VLAN apperances screws with that.

 

I have traced it down to the following:

 

1) The main master switch (a 3950) which defines all the VLANS has a vtp disable statement

2) Every remote switches lack this and lack a vtp client statement thus turning all of them into vtp servers. (apparently by default)  None of them define VLANS they are dependent on the VLAN appearing from their trunk port connections to be able to use it.

 

I didn't set this one up, a now defunct networking consultant company named Nexus did.  I do not understand why they set it up this way unless they simply didn't understand vtp - but there IS a vtp statement in the master switch that names a vtp domain - thus it makes no sense to me why you would name a VTP domain then disable vtp unless you were intending to set it up and then got sidetracked or something.

 

I know a couple ways to fix this - I can just disable vtp on all switches and let the switches use whatever it is they are going to default to use when vtp is disabled - or I can properly setup vtp, define the master switch as a vtp server, the remote site switches as vtp clients.

 

I am not really a fan of Cisco-proprietary garbage like vtp, eigrp and so on as I think they mainly were developed for very narrow specific problems and are massively abused for vendor-lock-in reasons.  This particular WAN seems normal enough and it does not seem to me there is a need for Cisco to stick it's nose into VLAN distribution but maybe there was a reason Nexus didn't disable vtp on the remote switches.

 

Some remote sites and the master site have additional 2950's daisy-chained off the ones plugged into the WAN for what that's worth.

 

So my quesiton is what is the best way to fix this?  Go with VTP and deploy it propery, or turn everything off?  I know that no matter what it's likely going to be a painful migration but fortunately all remote sites are in the same city so if I have to change it on the master then drive around to all the remotes to fix them that's doable.

 

Thanks!

11 Replies 11

Ted,

setting up the main site as VTP server and the remote sites as VTP clients seems like the best approach...but: where is the layer 3 (inter-Vlan) routing done ? You probably don't want everything to go to the main site and then back to the remote sites. How are the remote sites set up with regard to routing ?

I deliberately left the routing out of it because (in my opinion) the routing was done the worst way possible - which is as you might expect, everything IS going back to the main site - since all the remote switches are layer-2 switches. - and because I didn't want a bunch of "your doing it wrong" replies.  First, _I_ am not "doing it wrong", the prior consultant Nexus holds that honor, and secondly the client can't afford to lay out the green for new Cisco-green.  I have to work with what is there.  The one fortunate thing about it is that all their servers are at the main location so there is not a lot of remote-site-to-remote-site traffic.  (for now, at least although that may change)

I would approach this in a different way: Do you expect some degree of "dynamic" in the usage of new Vlans? If yes, configure it properly. I you expect it to be more static and that it's not needed to change Vlan-settings often, then just turn it off.

I should have clarified that the VLANS are not dynamic.  So you are saying then that whatever the benefits are of vtp they aren't going to be significant in a static VLAN situation?  Are dynamic VLANs the reason Cisco invented vtp?

 

And I assume also that you agree with my assessment of the problem?

Well, VTP can be a big help if you want to change the same Vlan-settings (like a new Vlan or to delete a Vlan) on a large amount of switches. But if there are not many changes or not that many switches that need the same Vlans, then it works perfectly fine without VTP. 

Thanks I will try turning it off on the remote switches report back on how that works.

Hello

 

 The problem is all the VLANS do not all appear in all sites.   There is a routed network superimposed on this but that's not important to the discussion other than to say the uneven VLAN apperances screws with that.

The question is do you need all the vlan in every site, vtp pruning manually is recommended to negate unwarranted traffic traversing your links.


You wouldn’t need to visit each site if you have access remotely.

If you dont wish to enable vtp the best approach would be change each switch to vtp transparent and if you need to extend your l2 then it would mean a manual approach to each switch every time. If you do wish to use it, (recommended)

 

1) check the vtp version and revision number on each switch ( ver 2 is incompatible with ver so make sure they are all running the same vtp version number

2) change each remote switch to transparent mode ( this reverts any revision number to zero)
 
3) On primary switch enable vtp server mode and specify a domain name( you can also create some dummy vlans so to increase it own revision number if its very low)

4) Make sure the switch interconnects at both ends are allowing the vlans you wish to be advertised to the remote switches.

5) on the remote switches make them vtp clients.

 

res
Paul

 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Paul the routed network superimposed on this is what prevents unwaranted traffic traversing the links. Each remote site is a separate VLAN and each VLAN is a separate subnet, so when a unicast packet is sent out it has a destination MAC address which is going to either be the router (at the main site, where all the servers are) or it's going to be a local port.  The remote switches may see all the VLANS but their ports are only in 1 of the VLANS and they cannot route to other VLANS so I don't think a switch would copy a unicast packet to every other VLAN present in the switch.

 

In short I don't think the negate unwanted traffic applies, here.

Hello

Maybe I have missed something in your OP - if you have extended L2 which means the same vlan -(broadcast) domain on different switche and they share the same L3 subnet  then you will have broadcast traffic and also again if you are allowing unnecessary vlans  to traverse the trunks then these could use up switch resources and bw- however if I mis unsderstood the OP and your not extending your L2 and it all L3 then you don't need worry about trunks,stp and vtp

res

pul


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

It is extended L2 and yes broadcast traffic will traverse the links.  But the question is, is broadcast traffic a large enough percentage of unicast traffic to impact it and justify complexifying the configuration to turn vtp on?  Not to mention that on top of all that there's a central DHCP server in use in this network so broadcast kind of HAS to traverse the links since the helpers are all on the main switch.  As I said before, _I_ didn't design this one and am only trying to make a poor situation less poor.

 

These are all fiber links and have a lot of bandwidth and nobody is complaining about speed.  I realize a purist would bend over backwards to make sure nothing was on the links other than what was absolutely required but I'm not a purist I'm a realist.   And a realist takes into account maintainence issues by future techs who might not be that well versed in things.

 

Considering in this installation the original installer wasn't well versed enough in bridging to know to shut off (or properly configure) vtp and you might see what I mean.  I can't prevent someone from deliberately shooting themselves in the foot in the future but I can avoid setting the beartrap that the last tech set for me.

 

Thus why I asked the question in the first place.  So far the reponses do not seem to indicate that there's any tremendous benefit to using vtp, that argues for turning it off.

Hello
So if your trying to make things better then advise
Would to keep vtp on - and manually prune the unwarranted vlans (Turing VIP pruning of) Follow the steps In my previous post so not to accidentally overwrite vtp database

Res
Paul

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: