10

I have several Layer 3 switch/routers which are all connected via an OSPF routed network. Also attached to each switch are two other networks. I have to assign a VLAN to each of these networks, I figure that I can just reuse the same two VLANS on each switch as all the traffic leaving the switch is untagged (as its routed, not on a VLAN trunk) - is there any reason I shouldn't do this and give each network a different VLAN? For example:

example

Ryan Foley
  • 5,509
  • 4
  • 24
  • 43
Raggles
  • 103
  • 5
  • 1
    Problems: a) confusion factor, b) mess created when one of those links becomes a layer-2 trunk. (and they are layer-2 interfaces first, unless you've no switchport'd them) – Ricky Sep 03 '14 at 08:11
  • Also, if all the switches are Cisco and running CDP, then it will demand even untagged ports have matching vlans on both ends. (lame, but it will) – Ricky Sep 03 '14 at 08:15
  • @ricky points noted thanks, however no cisco here, the ospf interfaces will never be trunks (and they are no switchport), as they are geographically diverse sites connected via radio equipment that doesn't care for vlans. – Raggles Sep 03 '14 at 20:35

4 Answers4

10

It's fine to reuse VLANs on segments that will never meet at layer 2.

Mike Pennington
  • 29,989
  • 11
  • 79
  • 152
bahamat
  • 867
  • 1
  • 7
  • 17
  • 9
    There is a reason: Reusing VLAN IDs may lead to confusion, especially at 3 in the morning when you ar on call and have to fix an outage. –  Sep 03 '14 at 07:33
  • 4
    You have more thant 4000 VLAN IDs available. I ask you, is there any reason you should reuse it? As @JensLink said, you need clarity when troubleshooting and reusing VLAN ID will note help you. – KorXo Sep 03 '14 at 08:02
  • 2
    I think this is probably the most appropriate answer for this situation. The networks are never going to meet at layer 2, and it is certainly feasible that in 10 years time that we would have several hundred sites like this, making vlan congestion a potential issue. Seeing as there is only one or two people responsible for this network confusion should be minimal (and if it breaks at 3am in the morning it can wait until after breakfast before it gets fixed anyway - no pesky customers here) – Raggles Sep 03 '14 at 20:46
  • 5
    Having the same vlan ids at multiple sites with different IP subnets and routed interlinks is definitely not an uncommon setup. And at 3 in the morning, it can also prevent some confusion to know that vlan 15 is your printer vlan, whatever switch at whatever location you are looking at... – Gerben Sep 04 '14 at 20:06
  • @Gerben has a great point : one of vlan's main use is to separate things for security (or bandwidth) reasons, so having the same VLAN# for the same kind of "content" helps a lot. Thus you reuse that VLAN# wherever the same kind of "content/security credential" occurs, on any site. So re-using, here, helps to ensure they are in the "proper" VLAN, and is less confusing, imo, than having VLAN naming change on each sites. But it may not be the OP's situation – Olivier Dulac Mar 31 '16 at 17:10
8

There is no significant reasons to use different vlan in your situation, but, some vendors(cisco at least) recommends to use this way:

for example, we have N branches, and we need four routed broadcast domains(LAN) on each, let`s calculate them:

branch1 = 1 branch2 = 2 ... branchN = N

  • worstations - ip:10.N.0.0/24, vlan 100+N
  • servers - 10.N.64.0/24, vlan 200+N
  • voice - 10.N.128.0/24, vlan 300+N
  • mgmt - 10.N.192.0/24, vlan 400+N

for tunnel interfaces networks, (we are) as usually, uses 172.16.0.0 network, with same rule: 172.16.N.0/30 - left side of the ring(or main uplink) 172.16.N.5 - right side of the ring(or reserve uplink)

if you have more than 255 branches, than you just need to use binary calculation, and you will get much more economical utilisation of address space(say if you need formula, i can provide it for you).

imho, this is good way, because you always know, in one look, what branch network, what branch vlan and what tunnel you are looking.

pyatka
  • 926
  • 4
  • 7
4

Here's another take in the opposite direction - a reason to reuse VLAN numbers since you can. I had a situation where I was working with some poor-quality IP phones that would download their configuration from a TFTP server, not from DHCP options. I wanted to be able to pick up a phone in any location and drop in any other without having to reconfigure, and the phones required the IP address and file name of the TFTP configuration to be statically configured on the phone. The config file had to specify the tagged VLAN number that the phones should jump to.

So, to make those horrible phones work the way I wanted, I had to make the voice VLAN the same VLAN number at every location. Sure I could have set up several different TFTP servers and/or config files and programmed each phone separately and reprogrammed them every time a phone moved. I just wanted to point out that there could be many other situations where re-using VLAN numbers would help you solve another problem.

Todd Wilcox
  • 1,135
  • 8
  • 19
  • 2
    If, as the OP's comment states, these are geographically diverse sites, then reusing VLAN numbers actually makes sense. A consistent, per site, VLAN numbering scheme will aid in troubleshooting and changes. Someone traveling to a site to fix or change something will then know, for instance, that VLAN 10 is always data and VLAN 11 is always VoIP. – Ron Maupin Apr 11 '15 at 16:15
  • Was your comment meant to agree with my answer? The tone sounds like disagreement but the content is in agreement. At the time I wrote this answer most of the comments were saying to NOT reuse VLAN numbers, and my answer was meant to make the case in favor of reusing them in some situations. – Todd Wilcox Apr 12 '15 at 03:23
  • No disagreement, no particular tone. I completely agreed with what you were saying. I only meant to emphasize on your answer that you could create a consistent, per-site scheme (data, VoIP, etc.) for separate sites. No offense meant. – Ron Maupin Apr 12 '15 at 03:29
  • Oh I didn't take offense. I got a downvote on this answer around the same time as your comment and wasn't sure if that was related to your comment, and since the other answers and comments have changed over the last six months, the phrase "alternate take" reads differently now and might be confusing. – Todd Wilcox Apr 12 '15 at 03:39
  • I didn't vote you down. I missed that, and I'm not sure why anyone would do that unless someone strongly disagrees with your answer. – Ron Maupin Apr 12 '15 at 04:00
3

There isn’t anything technologically wrong with it, but it's not ideal. From a design perspective it’s prone to problems down the road. Jens Link’s comment is very accurate; if you have an issue, this will compound the problem and complexity of trying to figure out what’s wrong. That would be even more exacerbated during intense, large-scale outages.

Although you haven’t mentioned network growth in your OP, it’s reasonable to assume that you’ll eventually deploy a switch downstream from one of your main routers. When you have matching VLAN-id’s in neighboring areas, this eliminates the possibility (well, makes it a PITA) of dual-homing connections to multiple upstream routers. You may not be forecasting this now, but it’s best to set things up for future success when it's an option, rather than a necessity.

Community
  • 1
Ryan Foley
  • 5,509
  • 4
  • 24
  • 43