Addresses in Python

ip_network will not quietly discard the host bits, because doing so would hide a mistake in a config file. The address .42 is a host inside the network, so it has bits set below the prefix, and the module says so plainly. Adding strict=False tells it that you meant a host address and want the network it sits in, and the result becomes 192.168.1.0/24. The prefix is valid, dotted addresses are the normal form, and a string is exactly what the function takes.

A /24 leaves eight host bits, so two to the power eight is 256 addresses. The first, 192.168.1.0, names the network and the last, 192.168.1.255, is the broadcast address, and neither can be assigned to a host, so hosts() yields the 254 in between. That is the total minus two the shell lesson works out by hand. The reserved pair is fixed rather than random, and hosts() behaves the same way for IPv4 and IPv6.

A /31 leaves a single host bit, so the block holds two addresses. There is no room to reserve one for the network and one for the broadcast, so the usual subtraction does not apply and both addresses are usable, which suits a point-to-point link where each end is a machine. Many calculators subtract two and wrongly report zero usable hosts. A /31 is smaller than a /30 rather than larger, and it holds two addresses, not four.

Four /26 blocks fit inside one /24, stepping by 64 because a /26 holds 64 addresses: .0, .64, .128 and .192. Python counts list positions from zero, so the third block is subs[2] and holds 192.168.1.128/26, while subs[3] is the fourth block at .192. This off-by-one is easy to make and worth meeting here, where the output is easy to read, rather than in a firewall rule where the wrong block would quietly let the wrong traffic through.