Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Why does 0.0.0.0 & 128.0.0.0 show up often in the Genmask?

1,584 views
Skip to first unread message

Geoff

unread,
Oct 17, 2015, 7:48:59 PM10/17/15
to
When I run a route command, I don't understand the results at all.
I admit that.
So, I ask just one specific question about these two sets:
Genmask = 0.0.0.0 & 128.0.0.0

I often see a genmask of one of the following sets:
Genmask = 0.0.0.0
Genmask = 128.0.0.0
Genmask = 255.255.255.255
Genmask = 255.255.255.0

And, I definitely get the "255" ones:
a. 255.255.255.255 = lets everything go through
b. 255.255.255.0 = lets the local subnet go through

But, I really don't get the intent/purpose of the other two.
Why split the Internet in half?

That makes no sense, to me. (but that's what they do)

Again, I repeat, I do NOT understand the route command,
even though I have been to multiple web pages, so, I'm just
asking about why those two genmask combinations.

I do realize there are many web pages on the route command:
http://www.cyberciti.biz/faq/what-is-a-routing-table/
http://compgroups.net/comp.os.linux.networking/how-to-interpret-route-command/1818314

But, I just don't get why they netmask to such strange numbers.

Here's the actual routing table I'm trying to interpret, but,
please don't tell me how it works because I want to figure that
out myself by understanding WHY they use 0.0.0.0 and 128.0.0.0.

$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.211.1.26 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
10.211.1.26 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
69.112.63.237 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
128.0.0.0 10.211.1.26 128.0.0.0 UG 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0

I just wish to know WHY they use 128.0.0.0 and 0.0.0.0?

William Unruh

unread,
Oct 17, 2015, 8:43:33 PM10/17/15
to
On 2015-10-17, Geoff <ge...@invalid.invalid> wrote:
> When I run a route command, I don't understand the results at all.
> I admit that.
> So, I ask just one specific question about these two sets:
> Genmask = 0.0.0.0 & 128.0.0.0

0.0.0.0 is the default
As a mask it makes everything into all 0. Thus a maskANDaddress=0.0.0.0
which is default.
128 is the eighth bit. Not sure where you see this mask.

>
> I often see a genmask of one of the following sets:
> Genmask = 0.0.0.0
> Genmask = 128.0.0.0
> Genmask = 255.255.255.255
> Genmask = 255.255.255.0
>
> And, I definitely get the "255" ones:
> a. 255.255.255.255 = lets everything go through

No, that mask gives the exact address back. Ie, only if the address is
exactly the same as the required address will it be selected.

> b. 255.255.255.0 = lets the local subnet go through

the top 24 bits are exact.



>
> But, I really don't get the intent/purpose of the other two.
> Why split the Internet in half?
>
> That makes no sense, to me. (but that's what they do)
>
> Again, I repeat, I do NOT understand the route command,
> even though I have been to multiple web pages, so, I'm just
> asking about why those two genmask combinations.
>
> I do realize there are many web pages on the route command:
> http://www.cyberciti.biz/faq/what-is-a-routing-table/
> http://compgroups.net/comp.os.linux.networking/how-to-interpret-route-command/1818314
>
> But, I just don't get why they netmask to such strange numbers.
>
> Here's the actual routing table I'm trying to interpret, but,
> please don't tell me how it works because I want to figure that
> out myself by understanding WHY they use 0.0.0.0 and 128.0.0.0.
>
> $ route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 0.0.0.0 10.211.1.26 128.0.0.0 UG 0 0 0 tun0

That says to put everything with the uppermost bit not set through the
tun0 interface.

> 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
Put everything not matched by any of the others through the wlan0
interface.

> 10.211.1.26 0.0.0.0 255.255.255.255 UH 0 0 0 tun0

Put the address exactly 10.211.1.26 through tun0

> 69.112.63.237 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
Put the address which is exactly 69.112.63.237 through wlan0

> 128.0.0.0 10.211.1.26 128.0.0.0 UG 0 0 0 tun0

Put everything with a 1 in the top bit through tun0

> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0

Put 192.168.1.x through wlan0

>
> I just wish to know WHY they use 128.0.0.0 and 0.0.0.0?

They are both more specific than the wlan0 route so everything that is
not either exactly 69.112.63.237 or 192.168.1.x through tun0 and those
two through wlan0

Geoff

unread,
Oct 23, 2015, 12:24:56 AM10/23/15
to
On Sun, 18 Oct 2015 00:41:25 +0000, William Unruh wrote:

>> I just wish to know WHY they use 128.0.0.0 and 0.0.0.0?
>
> They are both more specific than the wlan0 route so everything that is
> not either exactly 69.112.63.237 or 192.168.1.x through tun0 and those
> two through wlan0

I have been googling like crazy to understand what you were saying,
as the words take time to sink in, since the math is so screwy.

I now think the 128.0.0.0 is merely a clever trick to override the
default route without having to delete or change that default route.

Here, I think everything goes to 10.211.1.2 through the tun0 interface.
# route -n
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.211.1.2 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 10.211.1.2 128.0.0.0 UG 0 0 0 tun0

Does that interpretation of the two 128.0.0.0 lines work for you?

William Unruh

unread,
Oct 23, 2015, 12:38:54 AM10/23/15
to
Yes. Those two together cover the whole of the address space. And since
their mask is not 0.0.0.0 they are more specific than the 0.0.0.0 mask.
Thus everything not handled by the other even more specific rules will
be covered by these two,

>

Geoff

unread,
Oct 23, 2015, 1:06:45 AM10/23/15
to
On Fri, 23 Oct 2015 04:36:44 +0000, William Unruh wrote:

> Yes. Those two together cover the whole of the address space. And since
> their mask is not 0.0.0.0 they are more specific than the 0.0.0.0 mask.
> Thus everything not handled by the other even more specific rules will
> be covered by these two,

Thanks for the help because it took me a long time to figure out that
the VPN provider adds these specific "128" routes to just to override
the general "0.0.0.0" route without changing or deleting the general
route.

This default route is as general as it gets:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0

But this vpn-added route is more specific for half the Internet.

Destination Gateway Genmask Flags Metric Ref Use Iface
128.0.0.0 10.211.1.26 128.0.0.0 UG 0 0 0 tun0
Put everything with a 1 in the top bit through the tun0 interface.
10000000.00000000.00000000.00000000 anded with
10000000.00000000.00000000.00000000
-----------------------------------
10000000.00000000.00000000.00000000 = 128.0.0.0

And this vpn-added route is more specific for the other half.
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.211.1.26 128.0.0.0 UG 0 0 0 tun0
The genmask of 128.0.0.0 means only the first bit of the destination is significant.
Put everything with the uppermost bit not set through the tun0 interface to 10.211.1.26.
Since 128=1000-0000, 128.0.0.0 is 10000000.00000000.00000000.00000000
10000000.00000000.00000000.00000000 anded with
00000000.00000000.00000000.00000000
-----------------------------------
00000000.00000000.00000000.00000000 = 0.0.0.0

The VPN provider overrides the general route with this specific route.
Genmask 128.0.0.0 + Destination 128.0.0.0 covers 0.0.0.0 thru 127.255.255.255
Genmask 128.0.0.0 + Destination 0.0.0.0 covers 128.0.0.0 thru 255.255.255.255

Apparently the VPNs do this to avoid messing with existing routes.
They just add their routes when the VPN comes up, and remove them when the
VPN goes down.

They don't even need to *look* at the routing table to do this.
Now I can move on to figuring out the rest of the routes!

Geoff

unread,
Oct 23, 2015, 1:54:19 AM10/23/15
to
On Sun, 18 Oct 2015 00:41:25 +0000, William Unruh wrote:

>> 10.211.1.26 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
>
> Put the address exactly 10.211.1.26 through tun0

Looking at this for a while, I think the justification for
that conclusion is shown below (but I'm not wholly sure).

Destination Gateway Genmask Flags Metric Ref Use Iface
10.211.1.26 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
Put the exact address of 10.211.1.26 through the tun0 interface (directly).
The genmask of 255.255.255.255 means every bit of the destination is significant.
The gateway of 0.0.0.0 means you are directly connected to that interface.
Genmask 11111111.11111111.11111111.11111111 anded with
Destination 00001010.11010011.00000001.00011010
-----------------------------------
00001010.11010011.00000001.00011010 => passes only 10.211.1.26

I'm still a bit confused why we bother to AND the two addresses.
I could just as well just say that anywhere there is a "1" in the
genmask, the destination has to match, in order to be passed through.

So, the AND result confuses me (not the Genmask).

William Unruh

unread,
Oct 23, 2015, 12:31:55 PM10/23/15
to
On 2015-10-23, Geoff <ge...@invalid.invalid> wrote:
That is called the AND function. So you agree that they need to AND the
addresses. (and since a single bitwise AND is a very easily implimented
function on a processor, while looping through 64 bits and doing an IF
is horribly slow, any sensible person will do the AND.

>
> So, the AND result confuses me (not the Genmask).
Sorry, I cannot explain that.

>

Daniel47

unread,
Oct 27, 2015, 5:17:22 AM10/27/15
to
Using such definite values for AND'ing has always confused me .... if a
mask of 0.0.0.0 is used, then the only address reached would be 0.0.0.0
as it is the only address that would match the mask. Similarly using
255.255.255.255 would achieve nothing as every address would get
through, unchanged.

But, if you were masking your 10.211.1.26 with some other mask, say
72.186.30.231, the result might be something (some address) that was
totally different to your original address.

00001010.11010011.00000001.00011010 (10.211.1.26) AND'ed with
01001000.10111010.00011110.11101001 (72.186.30.231) results in
00001000.10010010.00000000.00001000 (8.146.0.8, I hope).

IMHO, of course! ;-)

Daniel

William Unruh

unread,
Oct 27, 2015, 1:00:09 PM10/27/15
to
No. It is the combination of the route-addressi (Destination) and the mask that is important.

You AND the mask with the address you want and compare it with the
route-address. Thus with a mask of 0.0.0.0 the only route-address that
makes sense is 0.0.0.0. And if the AND the mask with any desired address
you get 0.0.0.0 and it passes.
That is called the default route. It matches anything.

>
> But, if you were masking your 10.211.1.26 with some other mask, say
> 72.186.30.231, the result might be something (some address) that was
> totally different to your original address.

Yes, but why in the world would you use that mask? Usually masks are
designed to capture all addrsses in a certain range. That one would
capture addresses but not in a range.


>
> 00001010.11010011.00000001.00011010 (10.211.1.26) AND'ed with
> 01001000.10111010.00011110.11101001 (72.186.30.231) results in
> 00001000.10010010.00000000.00001000 (8.146.0.8, I hope).

Yes, and if the destination was 8.146.0.8 then 10.211.1.26 would pass,
otherwise not.
(I have not checked your math)

If (address AND mask = destination) then pass, else fail.

Daniel47

unread,
Oct 28, 2015, 6:29:19 AM10/28/15
to
On 28/10/2015 3:57 AM, William Unruh wrote:
> On 2015-10-27, Daniel47 <Dani...@eternal-september.org> wrote:

<Snip>

>> Using such definite values for AND'ing has always confused me ....
>> if a mask of 0.0.0.0 is used, then the only address reached would
>> be 0.0.0.0 as it is the only address that would match the mask.
>> Similarly using 255.255.255.255 would achieve nothing as every
>> address would get through, unchanged.
>
> No. It is the combination of the route-addressi (Destination) and the
> mask that is important.
>
> You AND the mask with the address you want and compare it with the
> route-address. Thus with a mask of 0.0.0.0 the only route-address
> that makes sense is 0.0.0.0. And if the AND the mask with any desired
> address you get 0.0.0.0 and it passes. That is called the default
> route. It matches anything.
>
>>
>> But, if you were masking your 10.211.1.26 with some other mask,
>> say 72.186.30.231, the result might be something (some address)
>> that was totally different to your original address.
>
> Yes, but why in the world would you use that mask?Usually masks are
> designed to capture all addrsses in a certain range. That one would
> capture addresses but not in a range.

Yeap, I understand that but even if I were to use just the first section
(72.0.0.0/72.256.256.256) or even the first and second sections
(72.186.0.0/72.186.256.256), I still think it's a waste!

>> 00001010.11010011.00000001.00011010 (10.211.1.26) AND'ed with
>> 01001000.10111010.00011110.11101001 (72.186.30.231) results in
>> 00001000.10010010.00000000.00001000 (8.146.0.8, I hope).
>
> Yes, and if the destination was 8.146.0.8 then 10.211.1.26 would
> pass, otherwise not. (I have not checked your math)
>
> If (address AND mask = destination) then pass, else fail.

So if I wanted something to go to 8.146.0.8, why don't I just send it to
8.146.0.8 and not have to worry about AND'ing something with something
else and hope that I get to 8.146.0.8??

Daniel


William Unruh

unread,
Oct 28, 2015, 12:35:39 PM10/28/15
to
And you would do that why? Netmasks are almost allways successive 1 bits
with no 0 interspersed. I donot know if the system regards yours as
legal

Please reread what I said and think about it.

Dan Purgert

unread,
Nov 2, 2015, 8:44:07 AM11/2/15
to
On 2015-10-28, Daniel47 <Dani...@eternal-september.org> wrote:
> On 28/10/2015 3:57 AM, William Unruh wrote:
>> On 2015-10-27, Daniel47 <Dani...@eternal-september.org> wrote:
>
><Snip>
>
>>
>>>
>>> But, if you were masking your 10.211.1.26 with some other mask,
>>> say 72.186.30.231, the result might be something (some address)
>>> that was totally different to your original address.

That's not a valid mask ... so, good luck there. :)

Netmasks start at 128.0.0.0 (i.e. 1000000.000[...]), and simply continue
swapping a '0' for '1' as you increase the netmask --
11000000.00[...], 11100000.00[...], and so on until you've got
11111111.11111111.11111111.11111111 (in CIDR notation /1 to /32). The
/0 netmask (0.0.0.0 in decimal or 00000000.0000[...]) means "anywhere",
and is pretty much reserved for the default gateway.

>>
>> Yes, but why in the world would you use that mask?Usually masks are
>> designed to capture all addrsses in a certain range. That one would
>> capture addresses but not in a range.
>
> Yeap, I understand that but even if I were to use just the first section
> (72.0.0.0/72.256.256.256) or even the first and second sections
> (72.186.0.0/72.186.256.256), I still think it's a waste!
>
> So if I wanted something to go to 8.146.0.8, why don't I just send it to
> 8.146.0.8 and not have to worry about AND'ing something with something
> else and hope that I get to 8.146.0.8??

Well, you could have a routing table for the entire internet in your
router if you wanted ... but ... with 2^32 possible addresses (less
127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and some other
reserved address space) at 4 bytes / address ... you're gonna need a lot
of space to hold it -- assuming the coffee's kicked in, about 2GB.

That's kind of a lot of space for a router ... and astronomical
considering IPv4 was designed in the 70s ...

BUT, by using the masks, we can compress the information into a lot less
space -- needing only 8 bytes (4 for the target address and 4 for the
netmask) in order to perform the lookups.

William Unruh

unread,
Nov 2, 2015, 1:24:11 PM11/2/15
to
On 2015-11-02, Dan Purgert <d...@djph.net> wrote:
> On 2015-10-28, Daniel47 <Dani...@eternal-september.org> wrote:
>> On 28/10/2015 3:57 AM, William Unruh wrote:
>>> On 2015-10-27, Daniel47 <Dani...@eternal-september.org> wrote:
>>
>><Snip>
>>
>>>
>>>>
>>>> But, if you were masking your 10.211.1.26 with some other mask,
>>>> say 72.186.30.231, the result might be something (some address)
>>>> that was totally different to your original address.
>
> That's not a valid mask ... so, good luck there. :)

I do not know whether a netmask with non-consecutive 1 would be used.
Certainly the result is defined ( and is not what he thinks it is) but
whether it would be used I do not know. Has anyone tried it?

I also do not know how precidence would be decided with such a netmask.
Is 128.0.0.1 ahead of or behind 192.0.0.0.

This question of course has nothing to do with his problems. He keeps
refusing to read carefully how netmasks work.

>
> Netmasks start at 128.0.0.0 (i.e. 1000000.000[...]), and simply continue
> swapping a '0' for '1' as you increase the netmask --
> 11000000.00[...], 11100000.00[...], and so on until you've got
> 11111111.11111111.11111111.11111111 (in CIDR notation /1 to /32). The
> /0 netmask (0.0.0.0 in decimal or 00000000.0000[...]) means "anywhere",
> and is pretty much reserved for the default gateway.
>
>>>
>>> Yes, but why in the world would you use that mask?Usually masks are
>>> designed to capture all addrsses in a certain range. That one would
>>> capture addresses but not in a range.
>>
>> Yeap, I understand that but even if I were to use just the first section
>> (72.0.0.0/72.256.256.256) or even the first and second sections
>> (72.186.0.0/72.186.256.256), I still think it's a waste!
>>
>> So if I wanted something to go to 8.146.0.8, why don't I just send it to
>> 8.146.0.8 and not have to worry about AND'ing something with something
>> else and hope that I get to 8.146.0.8??

And he need to read carefully, and go through a few examples to figure
out how netmasks and routes work. He has all the information, but
keep jumping to conclusions, rather than thinking.

>
> Well, you could have a routing table for the entire internet in your
> router if you wanted ... but ... with 2^32 possible addresses (less
> 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and some other
> reserved address space) at 4 bytes / address ... you're gonna need a lot
> of space to hold it -- assuming the coffee's kicked in, about 2GB.
>
> That's kind of a lot of space for a router ... and astronomical
> considering IPv4 was designed in the 70s ...
>
> BUT, by using the masks, we can compress the information into a lot less
> space -- needing only 8 bytes (4 for the target address and 4 for the
> netmask) in order to perform the lookups.

But his mind refuses to consider how netmasks work, and keeps assuming
he knows, when he does not.

William Unruh

unread,
Nov 2, 2015, 1:35:13 PM11/2/15
to
On 2015-11-02, Dan Purgert <d...@djph.net> wrote:
> On 2015-10-28, Daniel47 <Dani...@eternal-september.org> wrote:
>> On 28/10/2015 3:57 AM, William Unruh wrote:
>>> On 2015-10-27, Daniel47 <Dani...@eternal-september.org> wrote:
>>
>><Snip>
>>
>>>
>>>>
>>>> But, if you were masking your 10.211.1.26 with some other mask,
>>>> say 72.186.30.231, the result might be something (some address)
>>>> that was totally different to your original address.
>
> That's not a valid mask ... so, good luck there. :)

And interesting question ( which has nothing to do with his confusion)
is whether that is an invalid mask. Ie, the rules are very clear how to
use such a mask. Of course the precidence would be unclear-- is
128.0.0.1 higher or lower precidence(more or less specific) than 192.0.0.0?
both having the same number of 1 bits.
This question of course has nothing to do with his confusion. He has all
the information to understand how netmasks work, but refuses to apply
it, instead ignoring it and assuming he knows how it works. His
prejudices run away with his mind and blind him to reality.



>
> Netmasks start at 128.0.0.0 (i.e. 1000000.000[...]), and simply continue
> swapping a '0' for '1' as you increase the netmask --
> 11000000.00[...], 11100000.00[...], and so on until you've got
> 11111111.11111111.11111111.11111111 (in CIDR notation /1 to /32). The
> /0 netmask (0.0.0.0 in decimal or 00000000.0000[...]) means "anywhere",
> and is pretty much reserved for the default gateway.
>
>>>
>>> Yes, but why in the world would you use that mask?Usually masks are
>>> designed to capture all addrsses in a certain range. That one would
>>> capture addresses but not in a range.
>>
>> Yeap, I understand that but even if I were to use just the first section
>> (72.0.0.0/72.256.256.256) or even the first and second sections
>> (72.186.0.0/72.186.256.256), I still think it's a waste!

No. he does not understand. Think about which addresses that netmask (if
it were legal) would capture, even if we were to correct the "typo"
(lets be generous) of 256 as actually meaning 255. What would happen to the address
73.186.1.1? Would it meet this routing requirement or not?



>>
>> So if I wanted something to go to 8.146.0.8, why don't I just send it to
>> 8.146.0.8 and not have to worry about AND'ing something with something
>> else and hope that I get to 8.146.0.8??

Because different addresses go along different routes. Thus 127.0.0.1
does NOT get sent out over the ethernet.
and 10.0.1.17 probably gets sent to a different first hop than 172,156,3,1



>
> Well, you could have a routing table for the entire internet in your
> router if you wanted ... but ... with 2^32 possible addresses (less
> 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and some other
> reserved address space) at 4 bytes / address ... you're gonna need a lot
> of space to hold it -- assuming the coffee's kicked in, about 2GB.
>
> That's kind of a lot of space for a router ... and astronomical
> considering IPv4 was designed in the 70s ...

And think of what would happen if he used and ipv6 address space!

Dan Purgert

unread,
Nov 2, 2015, 4:18:18 PM11/2/15
to
On 2015-11-02, William Unruh <un...@invalid.ca> wrote:
> On 2015-11-02, Dan Purgert <d...@djph.net> wrote:
>> On 2015-10-28, Daniel47 <Dani...@eternal-september.org> wrote:
>>> On 28/10/2015 3:57 AM, William Unruh wrote:
>>>> On 2015-10-27, Daniel47 <Dani...@eternal-september.org> wrote:
>>>
>>><Snip>
>>>
>>>>
>>>>>
>>>>> But, if you were masking your 10.211.1.26 with some other mask,
>>>>> say 72.186.30.231, the result might be something (some address)
>>>>> that was totally different to your original address.
>>
>> That's not a valid mask ... so, good luck there. :)
>
> I do not know whether a netmask with non-consecutive 1 would be used.
> Certainly the result is defined ( and is not what he thinks it is) but
> whether it would be used I do not know. Has anyone tried it?
>
> I also do not know how precidence would be decided with such a netmask.
> Is 128.0.0.1 ahead of or behind 192.0.0.0.
>
> This question of course has nothing to do with his problems. He keeps
> refusing to read carefully how netmasks work.

There is no 128.0.0.1 netmask (at least no "standard" netmask with those
bits set - it starts from the left, and moves right (so 128.0.0.0 = /1,
then 192.0.0.0 = /2, 224.0.0.0 = /3 and so on, up to 255.255.255.255 =
/32), though as far as "precedence for network resolution" works, it
depends on your OS and the order things fall within the routing table.

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)

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

A windows host with the same networks would be the other way around, as
it's top-down.

William Unruh

unread,
Nov 2, 2015, 4:48:07 PM11/2/15
to
On 2015-11-02, Dan Purgert <d...@djph.net> wrote:
> On 2015-11-02, William Unruh <un...@invalid.ca> wrote:
>> On 2015-11-02, Dan Purgert <d...@djph.net> wrote:
>>> On 2015-10-28, Daniel47 <Dani...@eternal-september.org> wrote:
>>>> On 28/10/2015 3:57 AM, William Unruh wrote:
>>>>> On 2015-10-27, Daniel47 <Dani...@eternal-september.org> wrote:
>>>>
>>>><Snip>
>>>>
>>>>>
>>>>>>
>>>>>> But, if you were masking your 10.211.1.26 with some other mask,
>>>>>> say 72.186.30.231, the result might be something (some address)
>>>>>> that was totally different to your original address.
>>>
>>> That's not a valid mask ... so, good luck there. :)
>>
>> I do not know whether a netmask with non-consecutive 1 would be used.
>> Certainly the result is defined ( and is not what he thinks it is) but
>> whether it would be used I do not know. Has anyone tried it?
>>
>> I also do not know how precidence would be decided with such a netmask.
>> Is 128.0.0.1 ahead of or behind 192.0.0.0.
>>
>> This question of course has nothing to do with his problems. He keeps
>> refusing to read carefully how netmasks work.
>
> There is no 128.0.0.1 netmask (at least no "standard" netmask with those

I know. The question is whether or not the Linux routing allows such a
mask, and, if it does, how does it determine precidence. Of course if it
does not, then the question is irrelevant.

> bits set - it starts from the left, and moves right (so 128.0.0.0 = /1,
> then 192.0.0.0 = /2, 224.0.0.0 = /3 and so on, up to 255.255.255.255 =
> /32), though as far as "precedence for network resolution" works, it
> depends on your OS and the order things fall within the routing table.

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.

>
> 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.


>
> 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.

>
> 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.


William Unruh

unread,
Nov 2, 2015, 5:05:29 PM11/2/15
to
OK, I tried it out. The route command does not accept a mask with
non-contiguous 1 in the mask.
The ip route command does not even have the option of specifying a mask.
You must use the
128.0.0.1/24 type syntax, (that however does not work-- improper
syntax-- since the masked address could never give that output anyway
. So, yes, the mask must have contiguous 1 starting from the left.

So, the precidence is first the number of 1 in the mask, (more 1, higher
precidence) and then presumably the size of the masked address.

>

Dan Purgert

unread,
Nov 2, 2015, 6:55:42 PM11/2/15
to
On 2015-11-02, William Unruh <un...@invalid.ca> wrote:
> On 2015-11-02, Dan Purgert <d...@djph.net> wrote:
>> On 2015-11-02, William Unruh <un...@invalid.ca> wrote:
>>> On 2015-11-02, Dan Purgert <d...@djph.net> wrote:
>>>> On 2015-10-28, Daniel47 <Dani...@eternal-september.org> wrote:
>>>>> On 28/10/2015 3:57 AM, William Unruh wrote:
>>>>>> On 2015-10-27, Daniel47 <Dani...@eternal-september.org> wrote:
>>>>>
> [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".

Jasen Betts

unread,
Nov 3, 2015, 1:32:09 AM11/3/15
to
On 2015-11-02, William Unruh <un...@invalid.ca> wrote:
>
> I know. The question is whether or not the Linux routing allows such a
> mask, and, if it does, how does it determine precidence. Of course if it
> does not, then the question is irrelevant.
>

such netmasks are not allowed. all nemasks must have all the 1s on the
left, and all zeros on the right.

> 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.

no.



--
\_(ツ)_
0 new messages