Wireless Networks Thread, Whats best, Fixed or Dynamic IP? in Technical; Two questions to think off before using Static IP's or Reserverd DHCP Addresses:
How big is your school, how many ...
14th February 2009, 07:29 AM #16
Two questions to think off before using Static IP's or Reserverd DHCP Addresses:
How big is your school, how many clients machines do you have?
How many laptops do you have?
Where I am now, I have around 300 machines and very few laptops. This is doable. At the last school - 700ish machine, over half are now laptops. They'd find fixed IP a management nightmare.
I've never come across a scenario where I'd need static IP's on the desktop (admin staff and VNC excepted). If you use a good naming strategy then DHCP + DNS properly set up will give you all you need IMHO.
18th February 2009, 09:05 PM #17
Sure, numbers matter.
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!
18th February 2009, 09:34 PM #18
I find it much easier to adjust the DHCP Pool instead of creating reservations. For example, lets take a Class C network 192.168.x.x. I adjust the available DHCP Pool to 192.168.1.101 to 192.168.1.254, which means DHCP won't give out any IP below 101.
I then give servers static 192.168.1.5x , network printers 192.168.1.6x, access points 192.168.1.7x and admin workstations 192.168.1.9x.
18th February 2009, 09:35 PM #19
prolly being a bit dense here but can you run how you do the exclusion part.
Originally Posted by oldbaritone
18th February 2009, 09:35 PM #20
I like the above idea - good thinking
Originally Posted by Michael
19th February 2009, 07:01 PM #21
a matter of scale...
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.
"I then give servers static 192.168.1.5x , network printers 192.168.1.6x, access points 192.168.1.7x and admin workstations 192.168.1.9x."
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.
Thanks to oldbaritone from:
SimpleSi (19th February 2009)
By localzuk in forum *nix
Last Post: 19th October 2007, 09:28 AM
By chrbb in forum Hardware
Last Post: 1st December 2006, 12:48 PM
By Kyle in forum How do you do....it?
Last Post: 24th September 2006, 11:12 PM
By mark in forum Educational Software
Last Post: 30th December 2005, 09:30 AM
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)