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. 

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. 
–
PeterNov 9 '09 at 18:29

5 Answers
5

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. 

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. 

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 10.10.0.1 to 10.10.0.254 space, the subnet mask is 255.255.255.0.  If you change the subnet mask to 255.255.254.0, get the space 10.10.0.1 to 10.10.1.254, 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.