> [snip]
>
> I do not think so. It is specified as going from most specific (if one
> has all the 1 left justified, then the larger number of 1 in the mask
> determines that) to least specific. So I am asking IF it accepts
> non-consecutive 1 in the mask, how does it determine which is the most
> specific. If it does not accept such masks, then it is irrelevant.
Far as standard netmasks go, they're from leftmost bit to rightmost bit.
There is no "128.0.0.1" netmask (barring you doing something
non-standard, but then good luck getting that working on your devices).
/0 = 0.0.0.0 = entire IPv4 address space (256 "Class A" netblocks)
/1 = 128.0.0.0 = 128 "Class A" netblocks
/2 = 192.0.0.0 = 64 "Class A" netblocks
[...]
/8 = 255.0.0.0 = 256 "Class B" netblocks, AKA 1 "Class A" netblock
/9 = 255.128.0.0 = 128 "Class B" netblocks
/10 = 255.192.0.0 = 64 "Class B" netblocks
[...]
/16 = 255.255.0.0 = 256 "Class C" netblocks, AKA 1 "Class B" netblock
/17 = 255.255.128.0 = 128 "Class C" netblocks
/18 = 255.255.192.0 = 64 "Class C" netblocks
[...]
/24 = 255.255.255.0 = 1 "Class C" netblock
/25 = 255.255.255.128 = 0.5 "Class C" netblock
/26 = 255.255.255.192 = 0.25 "Class C" netblock
[...]
/32 = 255.255.255.255 = 1/256 "Class C" netblock (aka 1 host)
>
>>
>> In this example (Linux) table
>>
>>
0.0.0.0/0 (0.0.0.0)
>>
192.168.0.0/24 (255.255.255.0)
>>
128.0.4.0/22 (255.255.252.0)
>>
128.0.0.1/24 (255.255.255.0)
>
> Agreed that notation (/24) demands that the mask has all 1 consecutive
> from the left. My question is, if the mask does not have all 1
> consecutive is it accepted, etc.
Outside of a lab environment, the chances of being able to use a
non-consecutive string of 1s might as well be nil.
Inside a lab environment, the chances are slim -- most programming these
days (that I've seen anyway) expects you to use netmask (255.255.255.0)
or CIDR (/24) notation.
>
>
>>
>> the
128.0.4.0/24 network is "first" since Linux is in "bottom-up"
>> order. Note that given a complex enough network, you might be able to
>> make things slightly faster by
>
> Oops.
yup ...
"slightly faster by giving more direct paths"
>
>>
>> A windows host with the same networks would be the other way around, as
>> it's top-down.
>
> I do not believe that. I think it is specified in some RFC.
Possibly, haven't done windows networking in ages.
Note that my routing table was simplistic, as I wasn't including the
metrics (i.e. "weights" ) for the routes. Suffice to say it goes in
order unless there's also a lower metric for the same destination
network ... that is, an entry "
192.168.0.0/24 via 192.168.5.4, metric 1"
would be chosen over "
192.168.0.0/24 via 192.168.4.3, metric 10".