1

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!

9

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.

  • I agree with Evan, this is likely to be both painful and pointless. What is the actual goal here? And why does a 10-user network have two backup dc's? – cagenut Dec 2 '09 at 23:38
  • No problem on the insensitivity. I like straight and to the point. The reason I am doing this is we use OpenVPN and when users connect from home networks, they are unable to browse the net while connencted tot he VPN because the local addresses are 0.x and their home routers are 0.x as well. Yes I am a network newb. I am confused. I did not think I was subnetting my network. I always thought subnetting would be like 192.168.0.0/29 or something where I then change the subnet to 255.255.255.248 and only have 6 usable addresses. Then take another section of that same 0.0 with /28 etc. etc. – Physikal Dec 2 '09 at 23:38
  • I also just want to organize the network with lots of room for growth. Currently we have about 40 addresses used in total. By room for growth I also mean we have remote locations where I would have liked to put them into say 16.x and 17.x and so on to distinguish the difference by simply looking at addresses. If I stick w/ the 253 addresses in 0.x/24 spread over 4-5 locations vpned it gets limited quickly. Also, I'm talking out of my ass here and I hope it all makes sense. It sort of makes sense to me. I do the best I can lol. – Physikal Dec 2 '09 at 23:41
  • The 2 Backup DC's are on MSI Wind PC's that were setup for remote locations. Sometimes replication issues would come up so I could send one of the small backup DC's out to get a replication out before the tombstone period. – Physikal Dec 2 '09 at 23:45
  • 2
    Just to toot my own horn: serverfault.com/questions/49765/… – Evan Anderson Dec 2 '09 at 23:58
2

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:

  • 192.168.0.0
  • 255.255.255.0

Change the subnet mask settings on everything so:

  • 192.168.0.0
  • 255.255.0.0

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.

  • Port 0 - Gateway for 192.168.15.x network, IP address 192.168.15.1
  • Port 1 - Gateway for 192.168.10.x network, IP address 192.168.10.1
  • Port 2 - Gateway for 192.168.0.x network, IP address 192.168.0.1 (Optional during the migration)

Steps would be:

  1. Obtain a network switch for the server equipment
  2. Plug it into the router/firewall on a spare port and configure the router/switch to service the new server subnet 10.x from this interface
  3. Migrate servers across to the new subnet until none remain on the workstation subnet
  4. Overnight, reconfiguret the workstation subnet from 0.x to 15.x

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.

  • Your option 1 seems to be the most obvious way; there's no need to get too fancy with the setup for such a small network. – Maximus Minimus Dec 3 '09 at 10:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.