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??
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!
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.
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
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...