cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2650
Views
9
Helpful
6
Replies

Vlan per floor or switch??

dlawrence
Level 1
Level 1

Currently designing a Branch Office network and would like to implement a solution with a /26 subnet per switch. However the Operations guys would prefer a /24 per floor. Is there a definate Best Practice for this??

6 Replies 6

noran01
Level 3
Level 3

It depends on the size of the floor? How many network CPE devices per?

paul.matthews
Level 5
Level 5

Where would routing be done?

I favour smaller subnets - fewer broadcasts and in this age of malicious software should it become apparent that a single host is affected it is easier to justify switching off 40 or so people while you identify the infected device than 200 or more.

Depending upon where the routing is to be done, there is a greater chance of running inter switch links as L3 links, reducing the opportunities for spanning tree to get in the way...

Routing is to be performed at the Distribution layer. Floors will house no more than 200 users. I prefer smaller subnets, and although there are more arguments for smaller subnets than against what I need is a statement that says this is best practice!

Hi Dean

Just in case you are not aware of them Cisco have a number of design guides for campus/branch offices (among other things). Link is

http://www.cisco.com/go/srnd

To try and address your question. I am not aware of any definitve statements on the size of vlans on the floors because there are so many factors to take into account and a lot depends on your companies requirements/needs. You say there are more arguments for smaller subnets and if the advantages of smaller subnets outweighs the advantages of /24 subnets then you already have your answer.

One caveat to this would be that any designer must take into account the needs of the Ops people. If they are resistant to smaller subnets simply because it's new then hopefully you have a strong enough case to convince them otherwise. But they may have very good reasons for what they want.

Some things to take into account when deciding on size of subnets

1) Amount of broadcast traffic that your applications generate. If you have particular apps that use a lot of broadcasts you would want to look at smaller subnets.

2) Security requirements. Paul makes a very good point about a PC getting infected withn the vlan and the ease of propogation within the vlan vs across vlans.

3) Organisational setup of your users. This may or may not be relevant. For example if you have 200 users on one floor, 90 of who work in the same dept and need access to same servers it's easier to control access via layer 3 vlan access-lists than at layer 2 so it would make sense to have smaller subnets.

4) More vlans = more spanning-tree instances assuming you are using PVST+/RPVST+. This STP traffic needs to cross your uplinks although removing vlans from trunk links will help here.

5) More config needed on your distribution switches for smaller subnets ie. HSRP/STP root/secondary, L3 SVI's. Not a major one really but maybe one for your Ops people.

These are a few things to think about. One other thing, even if you go with a /24 i would recommend you have a separate management vlan on your switches so you will need at least 2 vlans per switch.

Just for completeness for user vlans we generally use /25's where i work, 2 vlans per floor.

Hope some of this has helped

Jon

Hi Jon,

Thanks for your input. The present standard is for a Mgmt LAN and 2 user vlans(1 voice+1 data). My concern is that the vlan per floor argument for user vlans(/24) doesn't scale, as larger offices will require more vlans per floor. eg, in the case of a floor with 300 users you will end up using 2 x /24subnets for data, one of which would be underutilized therefore wasting address space. A /26 subnet per switch would address this and from a design perspective be more scalable and waste less address space. I have already read most of the SRND docs, but there is no definitive statement. The problem here is that the Ops people are resistant to change unless we can prove that its Best Practice. Again many thanks for your input.

I think you will struggle to get a definitive statement either way on the VLAN per floor or VLAN per switch options, as it is all down to what isthe most appropriate. There used to be a guideline of switch where you cam route where you must, suggesting larger VLANs were good, but that was when there was a significant performance hit going via a router, now there is no real difference.

I personally prefer smaller VLANs for reducing the broadcast domain and easier isolation with less collateral impact in the case of problems - I am a person who had to shut off a large /20 or so during a virus hit!

/24s are a comfortable size for people to deal with - it is obvious when things are in the same subnet, so I would probably design around that for a campus network, but would adjust if the physical topology suggested it to be good. VLAN per floor is neat and tidy, and can scale - if you have 300 users on a floor you can use a /23 though I really don't like going that big. I would perhaps look at the area - when you are getting more than 200 on a floor you also tend to get names within the floor - 2nd floor east and west for example where they would also make neat demarcation lines for subnets, and if a floor really is that big, you may have the option of comms cabinets as the demarcation point.

In all cases the eighth layer of the seven layer model needs to be considered - the political layer. If the ops guys don't like it, you are probably on a loser, even if you can find nice clear statements that say use /28s everywhere!

You could pay £15k for me to come and write a report to say why a particular subnet size and allocation regime is best for you, but that is unlikely to help you if the ops guys have an issue. Any problem will be blamed on this "blooming stupid addressing scheme".

Basically you need to either at least make a nod to them in the way you address, or talk to them and persuade them why the way you want to do it

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: