Setting up IP numbers on a network.
-
I think having a huge subnet like that is personally a waste. It makes subnetting easier but it seems to just get too many IPs avaliable.
It really wastes nothing as the 172.16.0.0 (172.16/12 prefix) space is private RFC1918 range and the same IPs can be shared by multiple LANs. The only drawback I have found and it is minor is that it takes longer to scan my /22 than a /24 by a few seconds.
I avoid using the 192.168.x.x ranges here as far too many devices default to something in that range on a factory reset and it is aggravating to have them pop up on an IP you used for something else.
DHCP Static entries are at the bottom of the page here, they can also register the name with your DNS.
pfSense/services_dhcp.php See: DHCP Static Mappings for this interface.
and here with the ability to map new ones with less typing.
pfSense/status_dhcp_leases.php
-
The only thing wrong with using a subnet larger than necessary is it increases your chances of colliding with another private network's IP scheme.
It doesn't matter how large the subnet is. What matters is how many active hosts per collision/broadcast domain. With all things being equal, a 10.0.0.0/8 network will perform the same as a 172.30.234.16/28 network.
-
For what its worth, this is the scheme I use now:
Each LAN at each office gets a /22 e.g:
10.42.4.0/22 = 10.42.4, 10.42.5, 10.42.6, 10.42.7Then I allocate:
10.42.4.1-255 - Infrastructure - servers, random VMs, router, print servers, access points, VLAN switch… management interfaces10.42.5.0-255 - clients that are real work devices
10.42.6.0-255 - personal devices - smart phones, tablets... of staff and visitors from other offices and... whatever "crud" has been allowed
10.42.7.0-254 - DHCP pool - for getting an IP address when first connecting
I block internet access for the DHCP pool, so when someone connects their device to the network they get no internet and thus come to IT and ask. Then IT gives them a static mapped IP in the appropriate range, assuming they are authorized. Usually people who are not authorized do not even come and ask - they get no internet and then do not like to even admit they have connected their device to the WiFi.
Put limiters/traffic shaping on 10.42.6.0/24 so the personal devices can dribble down their app updates... without impacting real work.
-
Derelict, I'm not sure I understand the IP collision issue, aren't RFC 1918 IPs strictly for use on the local LAN and blocked at the internet level?
Network performance is as you say not a problem of size but performance of some things are directly tied to the size of the network. Take nmap as an example the larger your address space the longer it takes to probe it to see if there are any active responders on every IP.
A 256 host space:
stan@t310:~> nmap 172.16.0.0/24
…
Nmap done: 256 IP addresses (3 hosts up) scanned in 7.85 secondsversus
My 1024 host space:
stan@t310:~> nmap 172.16.0.0/22
...
Nmap done: 1024 IP addresses (17 hosts up) scanned in 16.23 seconds -
The only thing wrong with using a subnet larger than necessary is it increases your chances of colliding with another private network's IP scheme.
When using VPN for "road warrior" they will be coming from some cafe WiFi, other company office, home… all of which will have their own selection of private IP address space.
So if you use the whole 10.0.0.0/8 for the office, then a road warrior will have trouble when connecting from any "cafe" that is using any part of 10.0.0.0/8
If you use only as much private address space as you need, and pick a "random" bit, you reduce the chance of problems for road warrior clients. -
No. You can tell the DHCP server to always give the same IP address to a particular MAC address. So you just leave the computers on DHCP and you control what IP they get. On pfSense you can also insert the hostname into DNS.
Im not sure our router has that.
It really wastes nothing as the 172.16.0.0 (172.16/12 prefix) space is private RFC1918 range and the same IPs can be shared by multiple LANs. The only drawback I have found and it is minor is that it takes longer to scan my /22 than a /24 by a few seconds.
I avoid using the 192.168.x.x ranges here as far too many devices default to something in that range on a factory reset and it is aggravating to have them pop up on an IP you used for something else.
DHCP Static entries are at the bottom of the page here, they can also register the name with your DNS.
pfSense/services_dhcp.php See: DHCP Static Mappings for this interface.
and here with the ability to map new ones with less typing.
pfSense/status_dhcp_leases.php
(I use the 10.x.y.z and 172.16.x.y for something else)
Not sure If Im too sold on using /22…......I understand the idea and principle but....IDK.
-
Derelict, I'm not sure I understand the IP collision issue, aren't RFC 1918 IPs strictly for use on the local LAN and blocked at the internet level?
Network performance is as you say not a problem of size but performance of some things are directly tied to the size of the network. Take nmap as an example the larger your address space the longer it takes to probe it to see if there are any active responders on every IP.
A 256 host space:
stan@t310:~> nmap 172.16.0.0/24
…
Nmap done: 256 IP addresses (3 hosts up) scanned in 7.85 secondsversus
My 1024 host space:
stan@t310:~> nmap 172.16.0.0/22
...
Nmap done: 1024 IP addresses (17 hosts up) scanned in 16.23 secondsAs soon as we're IPv6 and every segment has 18 billion billion addresses all that is moot, so I don't see why it deserves attention now. At least where designing a network for the future is concerned.
-
As soon as we get IPv6 everywhere for everyone and everything IPv4 becomes less of an issue but not so much until then. When that happens is a big question.
I see myself running an IPv4 LAN for many more years, too many devices here that don't do IPv6 and are unlikely to be upgraded to do it in the future.
My ISP, Cox Cable has been promising an IPv6 preview / test program for at least three years now and so far there is no sign of it in the Phoenix market.
For me anything in the next five years is going to have IPv4 capability and I'll have to toss some still working hardware when I do a full cut-over to IPv6. At some point that becomes worthwhile but as far as I can tell from the Cox situation today I'm wasting my time even testing IPv6 stuff for at least 24 months and even after that I'm likely going to be using a tunnel to do IPv6 if I can't get a early-tester slot out of Cox.
I've done something similar with my computers, just tossed the last few 32 bit machines so my systems are all now Intel 64 bit ones. Makes things a bit easier to maintain and with the piles of cheap 64 bit XP machines being refurbished it only cost me about $600 to update three desktops and a laptop. It wasn't worth that to get out of the 32 bit business but added to all the other factors it tipped the scales enough to make it worth doing.
-
I'm just saying that sizing your network based on the time it takes to nmap it is kind of pointless.
-
Just for fun, there are 2^64 IPv6 addresses in a /64 IPv6 subnet - that is:
18,446,744,073,709,551,616There are 3,153,600 seconds in a year. Let's say your nmap can scan 1,000,000 (1 million) addresses per second, just to be ambitious.
So it will take 18,446,744,073,709 seconds, which is 5,849,424 years.
Hmmm - I don't think I want to wait that long just to find the IPv6 address of my lost device.
