oldbaritone

Good point, Jay. The previous posts were wanting 2,000 - 4,000 or more addresses in a subnet. Certainly by the time the address space has gotten that large, it's time to move away from flat topology and subnet the address space (like admin or curriculum) into smaller broadcast domains, like department or building or dorm. My explanation was about mechanics of the protocol, and certainly was not a recommendation to make domains that large. But if someone insists on being foolish, that's their prerogative. Thanks.

It's a little (okay, a lot) complicated, but to determine what's a "local" address to you, XOR the destination against your own address (i.e. find out what bits are different) and then AND that result with the net mask. If the result is zero, it's a local address; if not, send the request to your gateway. dsk, in your case, a student, let's say 10.64.92.123, tries to access an admin server at 10.64.90.1: (It's a lot easier to see this in Hex) 0A.40.5C.7B (student IP 10.64.92.123) 0A.40.5A.01 (admin IP 10.64.90.1) 00.00.06.7A (result of the XOR - just an intermediate result) FF.FF.FE.00 (255.255.254.0/23 Net Mask - AND against the above) 00.00.06.00 (result is nonzero, so dest is non-local and request goes to gateway) Now, do the same thing with the 248.0/21 Mask: 0A.40.5C.7B (student IP 10.64.92.123) 0A.40.5A.01 (admin IP 10.64.90.1) 00.00.06.7A (result of the XOR of the first two) FF.FF.F8.00 (255.255.248.0/21 Mask - AND with above) 00.00.00.00 (result is zero, so request is local and direct communication is used) In the first example, the request will be sent from the curri address to the gateway, which probably has IPsec rules to block traffic between the subnets. End result, the student in the curri subnet can't get to the admin server. In the second example, the request will be processed directly between the two clients. There will be no gateway involved in the request, so the student will be able to communicate with the admin server. This amounts to plugging all of your students onto the admin subnet - probably not a good idea. My suggestion would be to move one subnet farther away from the other subnet - at least to 10.64.128.xx if you can. The RFC1918 subnet reserves ALL of 10.x.x.x, so you might even want to look at moving the subnet block even farther - like 10.65.x.x, which would give you 65,535 addresses for each subnet. I'd guess it's probably easier to move the curriculum subnet, which is probably straight DHCP? Then you can have more space (i.e. use the 255.255.248.0/21 mask, or go to 255.255.240.0/20 - you can even go all the way to 255.255.0.0/16) without combining the subnets. krb548 - your "supernet" is really the same thing, the other way around. The "standard" subnet for 192.168.x.x is 255.255.255.0, which gives each client direct access to any address that has the same first 3 numbers in the IP, or a subnet of 254 addresses. Your "supernet" is just a larger mask access for local communication. "Good news-Bad news:" You're not going to be able to expand to 192.168.9.x, because that doesn't work in Binary/Hex. Your choices will be: 192.168.0.? - 192.168.0.255 (Net Mask 255.255.255.0) 192.168.0.? - 192.168.1.255 (Net Mask 255.255.254.0) 192.168.0.? - 192.168.3.255 (Net Mask 255.255.252.0) 192.168.0.? - 192.168.7.255 (Net Mask 255.255.248.0) 192.168.0.? - 192.168.15.255 (Net Mask 255.255.240.0) (the Binary/Hex is left as an exercise for the student...) ;-) (Tech note: some 192.168.x.x routers may have troubles with the ".0" and/or the ".255" addresses because they don't handle the subnet properly according to the spec. I'd suggest avoiding ".0" and ".255" address assignments in the 192.168 block because of addressing problems in cheap routers. And the "supernet" may or may not work in 192.168.x.x for the same reason - If it doesn't, go to either the 10.x.x.x subnet, or the 172.16.x.x-172.31.x.x subnet, which are also reserved addresses as specified in RFC1918)

which tells me that you have less than 10 network printers, less than 10 AP's, and less than 10 admin workstations. When it's that small, almost anything will work, and it's not too big a deal to make a static change station-by-station. No matter how you look at it, the amount of information that needs to be entered, whether static IP at a workstation or DHCP reservation on the server, is about the same. DHCP offers advantages like scope-level entries (such as name servers) so that a single entry in DHCP affects many clients. And when a particular machine is replaced, only the MAC needs to be reset in the DHCP reservation, and all other parameters will still be correct. When the clients are all in the DHCP reservation list, you don't miss updating one static client because someone forgot to enter it in their spreadsheet. You don't find yourself dependent on a "guru" who "has it all in his head" and "will write it up by the end of the week." (He doesn't.) You don't end up with two machines on the same static address because of a typo, trying to troubleshoot a phantom problem on two machines because the one turned on first works and the other one doesn't. (Tomorrow they get turned on in the other order, and machine #1 works fine, so you close the trouble ticket. Try troubleshooting THAT one between two different buildings, miles apart, with the other machine turned off!) DHCP won't LET you create a 2nd reservation for the same IP. It also won't let you have the same MAC in two different reservations. If a client pops up in the reserved address block that doesn't have a DHCP reservation, you can identify that something is wrong, immediately. Conversely, when an admin client shows up in the general pool, again it's immediately apparent that something is wrong. IMHO, it's all about keeping the control of the network at the network level, on the network server, rather than scattering important network control parameters across a wide topological (and perhaps geographic) area. It's about letting existing systems help you avoid errors and improve reliability. It's about handling change control in a centralized environment, rather than traveling to many remote sites and hoping to be able to get access to every machine on the first trip. (Somebody's always out of their office.) Static IP is simple, straightforward, and doesn't need a network server, DHCP server, or DNS server to work. But DHCP has obvious advantages for centralized control, accuracy, monitoring and security. In SOHO, it doesn't matter much. A complete top-down do-over (because the guru quit over a salary dispute) is only a couple of hours. But the SOHO owner won't be happy about the bill. In a larger environment, reverse-engineering the guru's IP structure can take weeks or months. And the alternatives in that situation are 1) outages until static IP's are all reset, 2) low reliability while you're figuring out who gets what access and why, and/or 3) security gaps during the update process. And again, the customer won't be happy about the bill. Been there. Done that. Got a tee-shirt. Don't need another tee-shirt. But I can't count the number of SOHO applications that have "grown" from two or three computers, one AP and one shared printer in a flat architecture, into a significant network with dozens of clients, many printers, and several independent departments who "want" to share among themselves, but "don't want any other department to see my machine or printer." Easy with DHCP, tough with static. Hotel/Motel and restaurant are other examples where networks may contain "privileged" subnets (reservations, billing or order processing) mixed in with "Free WiFi" for the customers. (AKA Security nightmare, just like student/faculty/admin issues) DHCP reservations are self-documenting if you fill in the "comment" field. Then the guru doesn't have leverage. Let him quit, the next administrator can pick up the pieces. And if guru tries malicious destruction of the DHCP server, the tables are backed up every day. Most local workstations don't get their static IP settings backed up overnight, because they're turned off when the backup runs; and that's only if you DO periodic backups of local hard drives. Whats "best", Fixed or Dynamic IP? - It depends on what you want to do. DHCP with reservations gives you an opportunity to get the best of both. What's the "best" car? Well, a Ferrari is cool, but if you want 50 MPG, Ferrari won't do it. A Prius might get 50 MPG or more, but it's not at the top of the "chick magnet" list. If you already have 5 kids, neither one will do what you need. And what if you want to tow your boat to the lake? My point is that you should understand both the benefits and shortcomings of whatever solution you choose. There's always more than one way to do something, but there's rarely "the best" or "the right" way. Any solution is based on assumptions and compromises. Make the decision with awareness and understanding, not just a quick-and-dirty "this will work." In my experience, front-end homework pays off later. And "experience is what you get when you didn’t get what you wanted." I've had LOTS of experience. Just my $0.02 - for whatever that's worth.

Absolutely I agree that sheer quantity of machines is a big question, but I delineate differently when the group size is large, breaking staff/admin/VPN out into the reservation groups/blocks, and leave the laptops/student machines and "wild cards" in the generic DHCP pool. My point mostly is that by using DHCP with reservations on the machines, rather than putting static settings on individual clients, network change control and administration is centralized and much easier. Simply make a single scope-level change at the DHCP server, and within a matter of hours the change will push out to all of the clients, without having to touch every single client machine. Keep the DHCP lease time reasonable; I usually use 8 hours. Within 4-6 hours the update is fully deployed. The students get different (and lower-priority/restricted) name servers and proxies; higher-priority is reserved for staff and admin, with student requests serviced on a resource-available basis. IPsec limits the access to the higher-priority (privileged) proxies to the staff/admin reserved address block only. Then add authentication and encryption layers, and security is relatively tight. Sure, the MAC can be spoofed, but then the kids run into the encryption and authentication, which gets alarmed and tarpitted on multiple failed attempts. Floating encryption keys and mandatory password changes keep things about as secure as an open campus can be. (Hmmm... why is a hardwire MAC from Administration trying to connect to a wireless AP in a dorm???... unsuccessfully, we hope...) But more importantly, DHCP with reservations keeps the end-users happier, because network-level technical changes are automatic and transparent to them. And that's a LOT less work for me. Happy Users + Less Work = Bliss!

Two tricks I've used - Reserve a block of IP addresses in DHCP, and then exclude the lot of 'em. Then only the MACs with reservations get in. The alternative I've also done is to exclude all but one or two IP's from DHCP, and then monitor them for activity. It gives me a "generic" address to bring the new machine up online before I enter a reservation for it - especially true with a laptop/notebook with a dock that has both a wired and a wireless connection. It also allows an exec to "play" with a "new toy" and get onto the intranet but not the internet. They're happier that way, and then I go over and tell them "you're supposed to bring new toys to us first..." and ipsec blocks against anything important for the "generic" address. But troubleshooting if you need to go to a sniffer (wireshark) is a lot easier if you have addresses in zones like classrooms or buildings. It also makes it easier to manage restrictions - IP blocks assigned to student areas, IP blocks assigned to teacher/professors, which may be in an office attached to a classroom, and IP blocks assigned to administration, even if the total-network topology is "flat." Of course, IP by userid (802.1x) works well for that, too.