Subnetting for Windows?

August 12, 2007 11:23 PM

How do I integrate several sub-networks for Windows/Samba compatibility in a rather complicated home-office environment?

I'm having trouble getting shared drives/folders to appear to computers on different subnets, on a weird amalgam of chained routers and hubs.

However, what's the best way to integrate the IP structure of an increasingly complicated network to facilitate sharing and a small server?

How do I properly subnet a network so DHCP is properly propagated and the subnets don't clash and act transparently as one network?

posted by loquacious to computers & internet (5 comments total)

You will need DHCP relay configured on whatever devices are acting as routers. Basically you tell them where the DHCP server is, and then configure the DHCP server with different settings for each subnet. That will take care of things from an IP perspective.

I would suggest evaluating if you really need to be subnetting... it adds complexity where it may not be needed.
posted by TravellingDen at 12:10 AM on August 13, 2007

The subnetting is happening by default due to consumer-grade router/hub/wifi points at two spots in the network, as well as physical size of the network.

I'm just trying to figure out how to get them all to play nice so things like Workgroup shares traverse the entire internal LAN.
posted by loquacious at 12:13 AM on August 13, 2007

Set up your "top-most" router (the one closest to the network connection coming into your house) as the lone DHCP server.

Set up any secondary and tertiary(?) routers (any routers plugged in to the top-most router directly or through another router) in DHCP "pass-through" mode (read your documentation).

Your private network space ("subnet") will then be coherent across all the routers. This will put you in a better situation to troubleshoot file sharing problems.
posted by Blazecock Pileon at 2:28 AM on August 13, 2007

If your goal is to get Windows Computer Browser service to work across all subnets, you have the problem of getting NetBIOS over TCP/IP to work reliably in different subnets, which not all home grade routers are going to do. If you read the linked article (second link is just a particular section of the first), Microsoft makes it sound like it some kind of deficiency in IP networks that makes their excellent browsing mechanism fail, and need workarounds, but really, NetBIOS is just an old, broken, non-routable protocol they grabbed before they understood the Internet. Nevertheless, if you're using SAMBA, and want to use Windows Computer Browser to get default discovery of shares on your network, as for friends bringing Windows laptops to your house, and wanting to browse your public folders on your server via WiFi, you're going to have to make some choices about which "workarounds" are better for your situation:

1) You could set up one of your wireless routers as the main WiFi Access Point, which would give out DHCP addresses, and then set up your second, and remaining "routers" as wireless "bridges" using third party firmware. There are actually several third party firmware replacements for Linksys routers, some of which can work on D-Link or other boxes, too, with the right internal processors. The trick is picking ones that explicitly support NetBIOS over TCP/IP on the hardware you have or will get, and being sure that they are configured to do so, as is your main access point. And then, all your clients need to have NetBIOS over TCP/IP enabled too, and that can slow down your wireless network considerably with NetBIOS broadcast packet updates on UDP ports 137 and 138.

2) A limitation of simple Windows workgroups is that they don't include the additional "functionality" of Windows Domain controllers, meaning that they don't have WINS and other NetBIOS hacks to overcome workgroup stranding across subnets (from the Microsoft linked articles above, under the section "Workgroup Spanning an IP4 Router"):

"A workgroup that spans an IPv4 router creates two separate workgroups. With workgroups, there is no mechanism to propagate the list of servers collected by the Master Browse Server on one subnet to the Master Browse Server on another subnet. Master Browse Servers for workgroups do not register a special NetBIOS name with WINS that may be used by workgroup Master Browse Servers or by browse clients. There are no special Lmhosts entries that are used to forward unicast workgroup browse list information between Master Browse Servers."

So, you could set up an old style Windows NT domain, via SAMBA, which would allow the Windows Computer Browser service to work via LMHOSTS file entries on Master Browser machines in each segment of your LAN. That's what a lot of people with this problem eventually do, and it works, and avoids most of the "chatty" NetBIOS over TCP/IP broadcast packet traffic that otherwise slows down wireless networks. It's a bit of a pain to have to do this, just to get Windows share browsing to work, but that's NetBIOS for you.
posted by paulsc at 3:49 AM on August 13, 2007

You might find that if you simply avoid using the WAN connection on any of your routers except the one that's actually connected to the WAN, and making that one the only DHCP server, that all your subnets become one and everything Just Works again.
posted by flabdablet at 4:20 AM on August 13, 2007