Setting up IP numbers on a network.
-
I'd leave it alone and not hassle it, personally.
-
I used to do this years ago - have a numbering scheme that gave ranges to each department (e.g. 50-59 dept1, 60-69 dept2…) but always the number of devices and size of departments... changes and any scheme gets mixed up. So I do not bother with such things any more.
But giving static mapped IPs in DHCP to all the resident systems (desktops and laptops that are normally at the office, even regular staff smart phones that connect to WiFi...) can be useful. Then you can make firewall rules to control "deviants" and any bandwidth monitoring/traffic graph... has the regular devices always at the same IPs. -
I use the MAC to IP and DNS name mapping and find it really simplifies stuff. I put my LAN at 172.16.0 and used a /22 mask so I have a roughly thousand IPs to play with. Way more than needed but it lets me pick IP numbers to group things and have plenty of room to add systems without juggling stuff.
I broke things into smaller chunks (on paper) so 172.16.0.X is all PC type computers, all the 172.16.0.00X ones are servers, 172.16.0.01X are the wife and grandkids. Then 172.16.1.X is printers, TVs, sound system and such. I stacked up by type and grouped by IP with lots of slack space for new systems. Next 172.16.2.X is my WiFi device range and last I put everything not assigned a static DHCP IP up in 162.16.3 and keep a careful eye on that range for intrusions.
I think of it as being four little (on paper) LANs but without any of the hassles of actually having individual real LANs.
I've given systems decent names so I rarely even think of the IPs unless something is broken. I'm using .home as my local domain name since it was proposed as an option in an RFC many years ago (now expired) and I never got around to changing it. Look at naming stuff as good practice for IP v6, you really don't want to be typing that stuff!
So I have system names like: pfsense, server, ntp1, ntp2, mybook1, lr-tv, br-tv. Easy to work with and I print the static mapping page as a cheat sheet.
-
I'd leave it alone and not hassle it, personally.
I just feel that if Im gonna redo it personally, a network I didnt setup from the start, I might as well start with a good base from the start, dont you think?
I understand your "If it aint broke, dont fix it" idea but…
I used to do this years ago - have a numbering scheme that gave ranges to each department (e.g. 50-59 dept1, 60-69 dept2…) but always the number of devices and size of departments... changes and any scheme gets mixed up. So I do not bother with such things any more.
But giving static mapped IPs in DHCP to all the resident systems (desktops and laptops that are normally at the office, even regular staff smart phones that connect to WiFi...) can be useful. Then you can make firewall rules to control "deviants" and any bandwidth monitoring/traffic graph... has the regular devices always at the same IPs.Well, Im sure that we wont have a huge amount of departments so I think leaving 20 or even 30 IPs for department is enough.
I mean, I think of it and we dont even have ROOM in our office for so many IP devices!
Currently, I do assign static IPs to every nonmovable IP device. It helps organize a bit better.
I use the MAC to IP and DNS name mapping and find it really simplifies stuff. I put my LAN at 172.16.0 and used a /22 mask so I have a roughly thousand IPs to play with. Way more than needed but it lets me pick IP numbers to group things and have plenty of room to add systems without juggling stuff.
I broke things into smaller chunks (on paper) so 172.16.0.X is all PC type computers, all the 172.16.0.00X ones are servers, 172.16.0.01X are the wife and grandkids. Then 172.16.1.X is printers, TVs, sound system and such. I stacked up by type and grouped by IP with lots of slack space for new systems. Next 172.16.2.X is my WiFi device range and last I put everything not assigned a static DHCP IP up in 162.16.3 and keep a careful eye on that range for intrusions.
I think of it as being four little (on paper) LANs but without any of the hassles of actually having individual real LANs.
I've given systems decent names so I rarely even think of the IPs unless something is broken. I'm using .home as my local domain name since it was proposed as an option in an RFC many years ago (now expired) and I never got around to changing it. Look at naming stuff as good practice for IP v6, you really don't want to be typing that stuff!
So I have system names like: pfsense, server, ntp1, ntp2, mybook1, lr-tv, br-tv. Easy to work with and I print the static mapping page as a cheat sheet.
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.
The PCs currently have "number names": COMP1, COMP3, etc….....But I really dont know whos computer is it. I mean naming things like CharliePC, RuthPC, etc. is kind of personal as we have prople that come-and-go and I would have to change their PC name to something else (which now that I think of it, wouldnt be that much of a issue thanks to DNS)
-
Well, then I would take the number of departments you EXPECT to have in the next 10 years and decide how many hosts you want per department and renumber.
You can leave them all on the same subnet but assign them IPs so you cen make rules later or put them on their own interfaces.
192.168.100.0/24
If you want 8 departments you can put 30 hosts per "subnet."
192.168.100.0/27 (1 - 30)
192.168.100.32/27 (33 - 62)
192.168.100.64/27 (65 - 94)
192.168.100.96/27 (97 - 126)
192.168.100.128/27 (129 - 158)
192.168.100.160/27 (161 - 190)
192.168.100.192/27 (193 - 222)
192.168.100.224/27 (225 - 254)Note that you would just leave all the netmasks as /24 in the actual interface configs.
You might also consider static host entries in the DHCP server over static IP addresses on the hosts.
-
Well, then I would take the number of departments you EXPECT to have in the next 10 years and decide how many hosts you want per department and renumber.
You can leave them all on the same subnet but assign them IPs so you cen make rules later or put them on their own interfaces.
192.168.100.0/24
If you want 8 departments you can put 30 hosts per "subnet."
192.168.100.0/27 (1 - 30)
192.168.100.32/27 (33 - 62)
192.168.100.64/27 (65 - 94)
192.168.100.96/27 (97 - 126)
192.168.100.128/27 (129 - 158)
192.168.100.160/27 (161 - 190)
192.168.100.192/27 (193 - 222)
192.168.100.224/27 (225 - 254)Note that you would just leave all the netmasks as /24 in the actual interface configs.
I would have 7 of those (even less with more hosts) and dedicate a range to switches, routers, PoE cameras, etc.
Im actually surprise that there isnt more people saying this is a good idea and its usually done like this.
You might also consider static host entries in the DHCP server over static IP addresses on the hosts.
You lost me there. Static host entires in the DHCP server? Isnt that a DNS job?
-
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.
-
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.
