Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So we're finally getting to a point where our simple, single subnet network wants to be broken up. Assume a sales/admin side and a development side. Where should I locate a common file server?

A subnet of its own?
On one or the other subnets?
Multihomed and on both sides?

Performance is not critical and this can really be made to work any way. More interested in the rationale and what will make the most sense going forward.


locked by HopelessN00b Jan 21 '15 at 10:44

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as primarily opinion-based by HopelessN00b Jan 21 '15 at 10:43

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Thanks for responses, and of course for followup questions. Having to fill some (large) experience gaps. The core issue is making the initial leap from the entire office on a single /24 with soho nat box to doing some routing in house. – Peter Nov 9 '09 at 18:29

Since you are segregating your network now, you might as well do it right the first time. Now, your actual end design will depend on your business needs but in general you should have the folling "classes" of networks:

  • Server
  • Infrastructure
  • Clients (in your case either subnetted or two seperate)
    • Sales/Admin
    • Development
  • DMZ
  • Backup
  • Test/Lab
  • Possibly an internal High security segment (PCI, HIPPA, etc.)
  • Possibly client/vendor DMZ

Having your network segmented this way will allow for growth in the future, as well as preventing you from having to give admins access to the developer segment if they don't need it.

If you really think about server placement now while you are going through the pain of migrating already and make allowances for future use, then when the time comes that you need to fully utilize this setup you won't have to completely reconfigure your network yet again.

Totally agree. Put any wireless networks in the DMZ. Why limit yourself if you have the ability to create subnets now? – Dave Drager Nov 6 '09 at 21:07

Depending on usage, really. If one team uses it more than the other, locate it on that subnet. If both teams use it the same, and you have a spare firewall/router, put it on it's own subnet. Don't have a spare firewall or router you can put it behind, or the traffic is very heavy, dual home it.

If you dual home it, you have to think about DNS/access methods for each group to make sure they're using the correct interface, rather than being routed to it.


Basically this is just my own personal opinion...

If you are expecting growth in the future of more "shared" network resources between the two VLAN's you could look at creating a 3rd VLAN specific to those shared resources.

This Vlan could house your File server for now and then any other shared resources later ( more servers / printers / etc )

We segment out our servers partly for organization, but as well, to isolate the backup traffic.

Routing between Vlans is also another way of controlling access with VLan specific ACL's.


The answer really depends on whether your switching and routing environment can easily support VLANs and if you have enough knowledge to deploy them.

If the answer is NO and you are not willing or able to make it YES, then I would make a bigger network (i.e. increase the size of the address space) by changing the network subnet mask. If you are currently using the to space, the subnet mask is If you change the subnet mask to, get the space to, adding 254 usable addresses.

Note: This is not a good long term solution, but it is a great temporary measure to buy some time. It has downsides, primarily around performance due to more broadcast traffic.

If the answer is (or will shortly be) YES, then my recommendation is ...

1- one VLAN for shared/common resources, such as servers and the internet firewall.

2- other VLAN's as you wish for workstations and other clients. DHCP will be your biggest headache .. it has to be setup for each VLAN. Typically a DCHP server can serve more than one scope, and the VLAN control switch can be told to pass DHCP requests properly.

3- once it is stable, use the central routing device (likely your main switch) to control/secure traffic among the VLANs.

This is a better long term solution, as it can grow and morph without much effort or performance issues.


Odds are good that the users will be accessing a "common file server" with the same protocol. Assuming you're moving to a multi-subnet architecture in order to use ACLs to limit traffic flowing between the subnets, the needs of the "sales/admin" versus "development" to access the file server, from a protocol level, are going to be the same. It ends up being "6 of one, half-a-dozen of the other" from an ACL perspective.

I'd put it in a "common server subnet" and apply an ACL to the inbound / outbound traffic from that subnet that treats all traffic the same regardless of source subnet.

I'd be curious for more background about why you believe your network "wants to be broken up". You shouldn't start subnetting an Ethernet LAN unless you have good reasons to do it. The best two reasons are:

  • Mitigating performance problems.

  • A desire to limit / control traffic moving between hosts at layer 3 or above.

I've got an answer that rated fairly highly that I'd refer you to for more commentary.