Increasing Subnet Size
-
Hi all
I'm new to pfSense, and by no means an expert in networking so I'm looking for some advice and answers to a few things I'm looking to do on my network.
Currently I have my system set basically to the defaults, LAN subnet 192.168.1.0/24.
I'd like to increase this to perhaps a /23. It will give me some more address space, and I will move all of my static mappings for machines into 192.168.0.0/24 space just to keep things neat, and expand my DHCP to take over all of 192.168.1.0/24.
What I would like to do is setup an IPSec VPN. That requires an unused subnet correct? Now I presume I could just assign it 192.168.3.1/24?
When I enlarge the subnet for my network will my static IP machines stop responding the the network because of the changes? They are mostly headless so I'm trying my best to not have the fight of getting on them to reconfigured.
Thanks
-
Currently I have my system set basically to the defaults, LAN subnet 192.168.1.0/24.
Ok, and why not setting up another IP net or working with VLANs?
I'd like to increase this to perhaps a /23. It will give me some more address space, and I will move all of my static mappings for machines into 192.168.0.0/24 space just to keep things neat, and expand my DHCP to take over all of 192.168.1.0/24.
In normal or the most two common ways to realize this will be the following;
-
Sort each LAN port with a dump switch and give each LAN port a different IP net such like;
eth0 = 192.168.2.0/24
eth1 = 192.168.3.0/24
eth2 = 192.168.4.0/24 -
Or set up some VLANs and each of them gets sorted with an own IP net such;
VLAN10 = 192.168.2.0/24
VLAN20 = 192.168.3.0/24
VLAN30 = 192.168.4.0/24
Also all VLANs could be set up on a Layer3 Switch and the pfSense firewall gets his own transfer net where
the IP address of the pfSense firewall is the gateway from that VLAN too.What I would like to do is setup an IPSec VPN. That requires an unused subnet correct? Now I presume I could just assign it 192.168.3.1/24?
One site with 192.168.2.0/24 –- vpn tunnel --- second site with 192.168.1.0/24
When I enlarge the subnet for my network will my static IP machines stop responding the the network because of the changes? They are mostly headless so I'm trying my best to not have the fight of getting on them to reconfigured.
About how many machines we are talking about? And how do you configure them normally?
-
-
I'd like to increase this to perhaps a /23.
I believe you may have to recreate the interface, as it doesn't appear you can change the subnet size of an existing connection. As for the static configs, since you're expanding down, they should keep working as long as you don't use any addresses in the expanded range. However, it's a bad idea to run with mismatched subnet masks, so you'd want to change the static configs sooner rather than later. The best situation would be to change everything all at the same time. If a device in the original subnet tries to send a packet to one in the expanded part, it will think the destination is in another network and then send the packet to the router for handling. The router will then send back an ICMP redirect, telling that device to send direct, which it can't do.
Bottom line, you're going to have to change the config on those static systems.
-
I believe you may have to recreate the interface, as it doesn't appear you can change the subnet size of an existing connection.
Edit the interface and change the netmask. Save. Apply.
-
I believe you may have to recreate the interface, as it doesn't appear you can change the subnet size of an existing connection.
Edit the interface and change the netmask. Save. Apply.
My mistake. I was trying to change the DHCP page, without changing the interface first. I hadn't had my beer yet. ;)
-
I've always heard a general rule of thumb is you don't want more than 200 devices on a broadcast domain. If you have that many devices you should break it down into VLANs or separate subnets. Once you get so many devices all those broadcasts and requests just flood the network and there gets to be so much overhead of all those extra packets. Can you do more? Yes, but the more you add the worse it gets. See if there is any way to divide the network and cut back the IPs in that subnet if you can.
-
Just don't forget to change all the devices on your LAN with static addresses their new /23 subnet.. Especially if you want to be able to print to that long forgotten printer across the room. ;)
-
I've always heard a general rule of thumb is you don't want more than 200 devices on a broadcast domain.
I was reading an article about that last week. That thumb no longer holds with IPv6, where there's no such thing as a broadcast. Multicasts are used and the only thing comparable to a broadcast is an all hosts multicast, which is used for things like router advertisements. Even ICMP neighbour solicitations, the IPv6 equivalent of ARP, are sent via solicited node multicast, where there's only a 1 in 16 million chance that it would be received by other than the intended recipient.
-
I've always heard a general rule of thumb is you don't want more than 200 devices on a broadcast domain.
I was reading an article about that last week. That thumb no longer holds with IPv6, where there's no such thing as a broadcast. Multicasts are used and the only thing comparable to a broadcast is an all hosts multicast, which is used for things like router advertisements. Even ICMP neighbour solicitations, the IPv6 equivalent of ARP, are sent via solicited node multicast, where there's only a 1 in 16 million chance that it would be received by other than the intended recipient.
I don't really know all that much about IPv6 but I have heard there is no broadcast. I assume that would mean that the soft limit would change but I never really thought about it. After 20 years it feels like IPv4 is still surprising me. Can't wait to dive into the IPv6 learning curve…
Just don't forget to change all the devices on your LAN with static addresses their new /23 subnet.. Especially if you want to be able to print to that long forgotten printer across the room. ;)
Yeah, absolutely important! We started doing work for a company and after like a week had to add a new PC. The previous company set the subnet to something crazy like .224 and statically assigned every IP and had none to spare. I had to go to every device on the network and reconfigure them causing a lot of unintended downtime! Definitely something to plan for.
-
I don't really know all that much about IPv6 but I have heard there is no broadcast. I assume that would mean that the soft limit would change but I never really thought about it. After 20 years it feels like IPv4 is still surprising me. Can't wait to dive into the IPv6 learning curve…
Yep, it's fact, no broadcasts. There are a lot of other things in IPv6 to improve performance over IPv4. One aspect that relates to the topic is the local subnet size is normally 2^64 or 18.4 billion, billion addresses. That should be enough for most people. ;)
You might want to learn a bit more about IPv6, as that's where the world is moving. According to Google, about 1/3 the Internet traffic in the U.S. is now IPv6. The overall principles are the same as IPv4, but there are differences beyond address size, such as no broadcast or ARP as I mentioned.
An excellent reference is IPv6 Essentials, from O'Reilly.
http://shop.oreilly.com/product/0636920023432.do -
Everything IPv6 would be a /64 anyway so you would never have this problem.
Unless you needed 19-billion-billion hosts on the subnet instead of only 18-billion-billion.
-
"such as no broadcast or ARP as I mentioned."
There is still broadcast type traffic in IPv6 just uses multicast.. And NDP is same sort of thing as arp… You have a client looking for the mac of a device with specific IP.. So saying broadcast or arp are no longer in ipv6 is a bit of a misnomer IMHO.. They just really changed the process, and it can yes really reduce the amount of traffic that every host sees vs say arp in ipv4.. But there are some real gotcha's to this.. So blanket statements like there are no broadcasts or arp can be very confusing to new users to ipv6..
What switches are being used in the environment??
Client looking for an IP going to send a NS And where is that going to go.. To the solicited node multicast address prefix or ff02::1:ff00:0/104 So while its not an actual "broadcast" it is a multicast node.. Now if your switch is using MLD (Multicast Listener Discovery) snooping.. Since that NS would have the specific IP its looking for and how this ties into the multicast group the specific device joined then sure a switch doing MLD snooping wold not need to flood every port.. And only the host with the IP being looked for would see this traffic, etc. And the switch would not have to broadcast it out every port..
But I am really curious whats happens with this traffic if your not using a MLD snooping switch? Ie your dumb switch, or simple "smart" switch with a very limited feature set.. Don't you like to mention that dumb switches pass vlan traffic… So in that sort of scenario how would NDP and the NS being sent to the multicast node address ff02::1:ff00:0/104 not be flooded to every port just like a broadcast?
lets not forget that for many many many years to come all these devices are going to be dual stack and sending broadcast.. So while L2 or broadcast domains in the future may be able to handle more hosts without issues when using switches with the appropriate feature sets.. Your still going to have to limit the number of hosts and not go going throwing 10k hosts on the same L2 because you don't need to worry about broadcast.. Since those 10k hosts are most likely still going to be using IPv4 at the same time..
-
"such as no broadcast or ARP as I mentioned."
There is still broadcast type traffic in IPv6 just uses multicast.. And NDP is same sort of thing as arp… You have a client looking for the mac of a device with specific IP.. So saying broadcast or arp are no longer in ipv6 is a bit of a misnomer IMHO.. They just really changed the process, and it can yes really reduce the amount of traffic that every host sees vs say arp in ipv4.. But there are some real gotcha's to this.. So blanket statements like there are no broadcasts or arp can be very confusing to new users to ipv6..
Broadcasts go to all devices, interested or not, and have to be processed. Multicasts don't make it past the NIC, so that reduces CPU load. This is even before snooping. NS ICMP uses solicited node multicast, where the last 24 bits of the multicast address contain the last 24 bits of the target IP. This means there's only a 1 in 2^24 chance of it being received by a device that's not the intended target. So, in all probability, only the target will have to process the NS, unlike ARP which every device has to process.
Also, just having IPv6 on a network will reduce broadcasts. For example, on my network all computers, tablets, smart phones etc. have IPv6. Only a few devices are IPv4 only. Now, if I want to access another computer, I'll be using IPv6, with NS, instead of IPv4 & ARP. Of course, on a network where all clients are capable of IPv6, there's no need for things like servers, network management, etc. to support IPv4 at all. Use IPv4 only when necessary and the number of broadcasts decrease.
So, once again, there are no broadcasts. The closest thing is, as I mentioned the all hosts multicast. And those are generally used only by routers to announce the network info. What swtiches is irrelevant, no broadcasts means no broacast. The problem with broadcasts is not the time on the wire, but the hit on the CPU to handle all those unwanted packets.Client looking for an IP going to send a NS And where is that going to go.. To the solicited node multicast address prefix or ff02::1:ff00:0/104 So while its not an actual "broadcast" it is a multicast node.
As mentioned above, it's extremely unlikely to make it past the NIC of any than the target. In the rest, it will be discarded by the NIC. Also, each device with an IPv6 address will have it's own multicast address for that IPv6 address. This is the multicast address used by NS.
Since that NS would have the specific IP its looking for and how this ties into the multicast group the specific device joined then sure a switch doing MLD snooping wold not need to flood every port.. And only the host with the IP being looked for would see this traffic, etc. And the switch would not have to broadcast it out every port..
Once again, a multitask will be discarded by the NIC, unless the device is listening to that multicast address.
But I am really curious whats happens with this traffic if your not using a MLD snooping switch? Ie your dumb switch, or simple "smart" switch with a very limited feature set.. Don't you like to mention that dumb switches pass vlan traffic… So in that sort of scenario how would NDP and the NS being sent to the multicast node address ff02::1:ff00:0/104 not be flooded to every port just like a broadcast?
Again the problem is broadcasts require CPU time to process. It has to be received by the NIC, sent up the stack and evaluated as to whether it's something the device is interested in. This takes CPU time away from other work. Multicasts are always filtered by the NIC and only passed to the CPU when appropriate.
But I am really curious whats happens with this traffic if your not using a MLD snooping switch? Ie your dumb switch, or simple "smart" switch with a very limited feature set.. Don't you like to mention that dumb switches pass vlan traffic… So in that sort of scenario how would NDP and the NS being sent to the multicast node address ff02::1:ff00:0/104 not be flooded to every port just like a broadcast?
MLD or not, the effect is the same. The NIC will not pass unwanted packets to the CPU. Also, MLD only affects subscribed multicasts, where a device joins a multicast. It does not affect things like NS, RAs etc. And as always, unwanted multicasts are discarded by the NIC, without bothering the CPU.
lets not forget that for many many many years to come all these devices are going to be dual stack and sending broadcast.. So while L2 or broadcast domains in the future may be able to handle more hosts without issues when using switches with the appropriate feature sets.. Your still going to have to limit the number of hosts and not go going throwing 10k hosts on the same L2 because you don't need to worry about broadcast.. Since those 10k hosts are most likely still going to be using IPv4 at the same time..
Yep, and all the more reason to move entirely to IPv6, as is already happening in some parts of the world, where transition methods are used to provide IPv4 access. That's the situation on my cell phone, where 464XLAT is used to access IPv4 only sites or for IPv4 only apps. However, even on an mixed network, moving things to IPv6 can reduce broadcast traffic. For example Windows file sharing has traditionally used broadcasts. But with home group networks, it's now IPv6 only and using multicasts, instead of broadcasts. The result, a significant drop in broadcasts, even though IPv4 is still on the network.
-
"MLD or not, the effect is the same. The NIC will not pass unwanted packets to the CPU"
Ok the cpu does not process it great - your switch is still sending the traffic. And while the packet is on the wire, not other packets can be on the wire.. This is the issue with this sort of traffic. Great your nic is not sending it to the cpu.. That is fantastic. But its EXTRA traffic on the wire while the cpu is still going to have to process all the normally IPv4 traffic.
My point is making blanket statements without clarification leads to FUD..
"Yep, and all the more reason to move entirely to IPv6, as is already happening in some parts of the world"
Sorry not… On the public side sure.. But no matter how much you want it.. Its not going to happen on the inside enterprise network for YEARS!!!!!
Your a huge fan - why don't you run a ipv6 only internal network? Good luck with that ;)
"But with home group networks, it's now IPv6 only and using multicasts, instead of broadcasts. "
You might want to sniff what actually happens when the files start moving ;)
-
^^^^
The problem with broadcasts is CPU load, not time on the wire. With gigabit commonplace, how much broadcast or unsolicited multicast traffic is there, compared to desired traffic? Incidentally, this is also the reason jumbo frames are often used in data centres, to reduce CPU load, for the amount of traffic carried. As for enterprise, if all the clients support IPv6, as pretty much all do now, why even provide IPv4 on a server? As for IPv6 only, that's already happening, as I mentioned with my cell phone. There are also some ISPs that convert IPv4 traffic, from the Internet, to IPv6 to their customers. In that situation, an IPv6 only local network is entirely possible. Don't configure IPv4 addresses and no more ARP or DHCP broadcasts.IPv4 will be around for a while yet, but it's declining. Hopefully, one day we can get rid of it entirely. At the moment, the only IPv4 traffic on my network is for those IPv4 only devices and accessing IPv4 sites on the Internet. Declining IPv4 means declining ARP and other broadcasts.
You might want to sniff what actually happens when the files start moving ;)
Actually, I have. Home group uses IPv6 link local addresses exclusively. It does not work over IPv4 at all. Anyone who tries to disable IPv6 on Windows, while using home groups will soon discover that.
Incidentally, there's a trend in data centres that reduces even the time on wire effect. Spanning tree has long been used in data centres, but that forces all traffic into the best path to the root switch, leaving much of the network blocked. Spanning tree is now being replaced by Shortest Path Bridging, where there's no such thing as a blocked connection. Any link between switches can be used, if it's the shortest path. SPB works by essentially creating VLANs between switches, by adding on another MAC header for transit between switches.
BTW, stating fact does not create FUD. FUD is caused by misinformation, such as NAT is a "security feature" that IPv6 doesn't provide. In fact, the security of NAT comes from the state full connections it needs to work. Well state full firewalls do exactly the same thing. Yet despite that, people still claim that NAT provides security. Now that's FUD.
