Subnetting will always be a "2n" bit-wise operation. Subnets fall on specific bit boundaries, no matter what. You can't subnet on arbitrary boundaries or addresses. Just think, "always equal proportions." Not any different than cutting a pie into equal proportions.
I always use a /24 as a "base" to start from. Again, this is a 2n (ie multiply or divide by 2) operation, so you go from a single subnet, to two halves, or four quarters, or eighths, sixteenths, etc.
If you split a /24 into two halves, each one of those halves will be a /25 subnet.
If you split a /24 into four quarters, each one of those quarters is a /26 subnet.
If you split a /24 into eighths, each eighth is a /27 subnet.
The converse is true when going in the opposite direction.
If you combine two /24's into a single subnet, you end up with a /23.
If you combine four /24's into a single subnet, you end up with a /22.
If you combine eight /24's into a single subnet, you end up with a /21.
To answer your question, if you split 10.10.16.0/24 into two equal-sized subnets, you end up with:
1. 10.10.16.0/25
2. 10.10.16.128/25
The first and last usable from each subnet would be:
1. 10.10.16.1/25 and 10.10.16.126/25
2. 10.10.16.129/25 and 10.10.16.254/25
Hope this helps.
"Nesting" (overlapping networks) requires proxy-arp and therefore SHOULD be avoided at all costs. No enterprise router will allow such a broken configuration -- each interface/subnet must be completely independent, which means out in the real world, where real IP addresses are routed, this method of "conservation" cannot be used. (aka: nonsense) [*]
It SHOULD not be attempted by anyone not thoroughly versed in networking. (i.e. if you haven't been designing, setting up, and maintaining large, complex networks for a decade or more, you shouldn't even be talking about this type of damage.)
(Full disclosure)
I'm doing this exact thing in an OpenStack development environment right now. 192.168.xx.0/24 has a /29 behind one of the machines in the larger /24. That machine has to have a number of specific, non-default setting changed to pretend to be hosts within the /29 slice. (aka proxy-arp) Yes, I can add a route for the /29 on the router, but the machines in the /24 still won't be able to talk to the /29 because their larger netmask means they're link-local; I'd have to add that /29 route to all the machines in the /24 for them to work.
All-0 and All-1
Those concepts haven't had any tangible meaning in modern networking for decades. Nothing you're likely to run into on the internet makes any assumptions about network size -- everything is classless now. Yes, there used to be issues using an all-0 (or 1) subnet -- say 199.72.0.0/24 (the first subnet from 199.72.0.0/16) (true story) -- because some random system on the internet (AIX) applied class logic to the range. Nothing does that today. So, with 199.72.0.0/16, the address range is 0.0 to 255.255 -- with the those too addresses being the /16's network and broadcast addresses. Those are always the /16's network and broadcast, even if a /24 were nested with it somewhere.
The active netmask ALWAYS defines the network and broadcast. Yes, that means a nested construct has multiple broadcast addresses, but due to different netmasks, nodes within different zones (sub-network, parent-network, ...) listen to different addresses. At layer-2 (ethernet), all hosts in the same domain (eg. vlan) see the same broadcasts but the host will filter out, at layer-3, the "foreign" broadcasts, unless they're sent to the "all nodes" broadcast address of 255.255.255.255.
[*] ISPs wanting to conserve space like this do it via bridging, but that has it's own problems.
[*] I warned my idiot ("we know more than you") coworkers not to use 199.72.0.0/24, but they did it anyway -- putting the webdev desktops in 0.0/25. A day later came the "What. Did. I. Tell. You." after complaints from every single person about random places on the internet they simply couldn't get. That was in 1997.
Best Answer
There is no possibility of an overlap with FLSM. There can only be an overlap with VLSM. To that end, it will be much easier to "find" an overlap in FLSM, since there never is one. Whereas "finding" a overlap in VLSM will involve some binary math. Let me explain.
FLSM, or fixed-length subnet mask implies every mask is the same across multiple subnets.
For example, breaking up a Class C network (aka, /24) into FLSM sub-networks of /27 would yield ONLY these results:
These are the only 8 possible /27's within a /24. Every NetID listed above represents a subnetwork that includes addresses of the NetID itself, and the following 31 addresses.
There is no such thing as a x.x.x.150/27 address, the NetID and mask do not pair, so there is no way to have a /27 range represent 150-181 (and would therefore introduce an overlap possibility).
As a result, in FLSM, there is no possibility of an overlap if you are using NetID's and Masks that pair properly.
VLSM, or variable-length subnet mask implies every mask is not necessarily the same across multiple subnets.
For example, there are countless ways to break up a /24 into multiple subnetworks, one of which might be...
To find overlaps, you would have to calculate the IP range for each subnet, and ensure that no IP addresses are "counted" twice. That involves doing the traditional subnetting math.
Since the masks differ for each subnetwork, in VLSM, there is absolutely a possibility that an overlap exists.
To close, I pose the question to you. Every NetworkID and SubnetMask above pair properly, which is to say they represent a valid subnetwork and subnet mask combination.
As we learned, with properly paired FLSM, there is no overlap. With properly paired VLSM, there might be an overlap.
In the Ssb-network list above, there is an overlap in the VLSM range above. Can you find which it is? How easy was it, comparatively?