I am preparing to undergo a pretty massive IP restructure. Currently we reside on one subnet. 192.168.0.x / 255.255.255.0.
Gateway + Firewall = 192.168.0.15 (T1 and ADSL tie into this)
Active Directory DC + DNS + DHCP (I know, all on one server, big no-no, its 10 people locally) 192.168.0.150
Backup DC1 = 192.168.0.151
Backup DC2 = 192.168.0.152
Mail Server = 192.168.0.43
I have a mixed environment of windows and linux boxes.
DHCP Scope hands out 192.168.0.170-254
3 Static IP Network Printers
About 10 other misc linux/windows servers.
I would like to set it up so that all static addresses (servers, printers, etc.) are on 192.168.10.x, and all DHCP addresses are on 192.168.15.x.
However, when I was going through testing I noticed something that really made me think I'm underestimating the size of this project. I was assigning a static address to a server 2003 box and I was giving it an address of 192.168.10.33, then I entered the gateway of 192.168.0.15. It warned me that the gateway was on a different subnet. Will I need a different gateway for each subnet? 192.168.10.x and 192.168.15.x? Can I just setup an IP address alias in my firewall so it spits out 192.168.10.15 as well as 192.168.15.15?
In my mind, for this restructure I simply setup the DHCP scope in MS DHCP, reconfigure all the servers so their static addresses are 10.x instead of 0.x, reboot all the workstations. DNS will sort itself out on its own. Setup the FW/Gateway so that it has the static of 10.x w/ an alias of 15.x. Is that a safe assumptiong? Also accounting for about 10+ hours of crazy problems that usually come w/ anything like this.
Any help or links to guides would be greatly appreciated. Thanks!
This is probably going to sound callous and insensitive, but I sense that you're potentially heading toward a train-wreck.
Your use of subnets with ".10" and ".15" in them make me think you're doing this purely for aesthetic reasons (since these aren't even powers of 2). Arranging IP addresses to be "pretty" creates work and doesn't actually accomplish anything useful.
There are only 2 reasons for subnetting a LAN:
Performance problems because of a large broadcast domain, either because of broadcast packet traffic or flooding of frames to unknown destinations by your Ethernet switches
Packet / traffic filtering at "choke points" to enforce policy or for security concerns
Beyond those reasons, there's no reason to subnet a LAN.
Not to be rude, but your asking of questions like "Will I need a gateway for each subnet?" makes me think that you could probably use a lesson on IP routing and subnetting. There's a couple of good answers here on Server Fault that talk about that. If you don't know how to do what you're planning on you're going to end up with a mess.
If any part of the process of hosts communicating on an IP network running on Ethernet is a mystery to you (i.e. how ARP works, etc) then you'd do well to learn a bit about it before proceeding.
Your proposed configuration is more complicated than you think it is. Your DHCP server, addressed in the 192.168.10.0/24 subnet, isn't going to hand out leases for 192.168.15.0/24 addresses, for example, w/o your router performing DHCP relay for the clients. You're going to be routing all the traffic between your clients and your servers through your router, so unless it can handle wire-speed Ethernet traffic you're going to be creating a bottleneck. In general, I'm not seeing any advantages to your proposed configuration.
Why are you doing this, anyway? It sounds like you have a very small number of hosts, so you shouldn't be running out of addresses in the 192.168.0.0/24 subnet. (I can understand wanting to get away from 192.168.0.0/24 because many home users attempting to access your network via VPN are going to have problems, what w/ so many home routers shipping using the 192.168.0.0/24 subnet "out of the box". Other than that, though, I can't think of a good reason to change...)
Your comments help-- thanks.
You're "subnetting" because you're looking at creating multiple IP subnets. In order for a host to communicate off of its subnet, it needs another host to facilitate that communication-- one that has interfaces on both the source and destination subnets. That's a router (a "gateway").
Here's how I'd plan your network, w/ what minimal knowledge about your business that I have:
If you're not planning to have more than 254 hosts at your "main" site, change everything there over to something like "192.168.127.0" with a "/24" (255.255.255.0) subnet mask. If you're worried that 254 hosts at the "main" site isn't enough, change that to "192.168.126.0" with a "/23" (255.255.254.0) subnet mask, making your valid hosts there 192.168.126.1 to 192.168.127.254.
Start numbering your remote sites at "192.168.128.0/24" and continuing to "192.168.129.0/24", etc. If you're worried that a remote site might have more than 254 hosts, do the numbering as "192.168.128.0/23", "192.168.130.0/23", etc, giving each remote site 510 possible hosts.
Any IP address with a 3rd octet greater or equal to 128 will be a remote site. Anything less will be the "main site". Assuming you're not planning on having more than 127 remote sites (each with 254 hosts, if you go w/ /24 subnet masks for the remote sites) you'll fit in this IP scheme fine. (You could have 63 remote sites, each with 510 hosts, as well...)
If the "main site" continues to get bigger and bigger you just keep expanding its subnet down towards 192.168.0.0. Your "main site" could end up with 32766 hosts in the "main site" network (but, at that point, you'd probably have broken it up into multiple subnets internally. VLSM-wise, though, the main site would summarize to 192.168.0.0/17 and the remote sites would summarize to 192.168.128.0/17.)
Ultimately, such a strategy would allow for a lot of growth, and fairly small core routing tables. It's not the "right answer"... it's just an answer.
That probably doesn't make a lot of sense, but I'd recommend reading up until it makes at least partial sense. >smile<
I really wouldn't get hung up on creating "ranges" of IP addresses in your subnets to place servers, printers, client computers, etc. DNS allows you to identify hosts. Memorizing that "xxx IP addresses are assigned to printers" is a waste of your brain power, IMO. I make the entire subnet available for DHCP, put in reservations for any statically-configured devices, and use the DHCP database as my "IP address reference" rather than making the classic soon-to-fall-out-of-date Excel spreadsheet of IP addresses. I name every host, make sure that DNS is updated (both forward and reverse zones), and live happy w/o clogging my memory with IP address information.
The two easiest options I know of:
Option 1
Expand the existing subnet to be much larger and accomodate everything.
Pro: Real simple
Con: Just one broadcast domain
You currently have your setup like this:
Change the subnet mask settings on everything so:
The gateway can now be anywhere in the range: 192.168.x.x
Option 2
Add a gateway to each networks
Pro: Seperation of subnets and broadcast domain
Con: More networking configuration required. May need to re-patch equipment
Seperate the subnets physically using seperate switches, or virtually using vLANs. Connect both networks via seperate connections to your router/firewall. Configure the router as a gateway for each interface and configure the appropriate traffic rules between the subnets to allow users access to the server resources they require. e.g.
Steps would be:
Option 1 seems the best move if you just want more available IPs. If you're doing this to segregate your network, Option 2 is the way to go... and I'd advise vLAN-ing off the new subnet + gateway IP, then migrating port-by-port into it.