Q: bad routing table cache entries

ip route get 91.189.89.238
91.189.89.238 via 192.168.0.1 dev eth0 src 192.168.10.202
cache <redirected>

Now, 192.168.0.1 is also a valid gateway, but it is outside of the network mask for the eth0 interface:

So my question is: why does linux allow an invalid redirect entries? Is it a problem with my setup, or some kernel bug, or some router setup problem? Where should I look into, to nail this down?

Quoted 4 lines

ip route get 91.189.89.238
91.189.89.238 via 192.168.0.1 dev eth0 src 192.168.10.202
cache <redirected>

         :

Quoted 2 lines

Now, 192.168.0.1 is also a valid gateway, but it is outside of the network mask for the eth0 interface:

         :

Quoted 4 lines

So my question is: why does linux allow an invalid redirect entries? Is it a problem with my setup, or some kernel bug, or some router setup problem? Where should I look into, to nail this down?

Seems like the problem is in the router that is sending the bad redirect. You would have to check into the configuration and/or implementation of the router- it should not be sending back a redirect in the above case (different netmasks) even if the ingress and egress physical interfaces are the same.

Router on 192.168.8.1 is just a PC with ubuntu, w/o any special software. I'd be very surprised if it does so. As I understand, linux would accept such ICMP redirect only from the router, or could someone else also send them?

But what worries me more, is the question:
Should the linux kernel really silently accept those, breaking the routing in a completely unexpected ways? Isn't it a bug?

The sanity check against netmask looks trivial, so why it is not there?

Quoted 4 lines

Router on 192.168.8.1 is just a PC with ubuntu, w/o any special software. I'd be very surprised if it does so. As I understand, linux would accept such ICMP redirect only from the router, or could someone else also send them?

If someone elase can spoof redirects on your network, you have a much bigger network management problem- at that point, how can you trust anything, e.g., a default rdisc rtradv?

Quoted 3 lines

But what worries me more, is the question:
Should the linux kernel really silently accept those, breaking the routing in a completely unexpected ways? Isn't it a bug?

How is the receiver supposed to know that the redirect was "bad"?

In your example, you claimed that

a "good" redirect was:

     ip route get 91.189.89.237
     91.189.89.237 via 192.168.8.1 dev eth0  src 192.168.10.202
         cache

but a "bad" one was:

    ip route get 91.189.89.238
    91.189.89.238 via 192.168.0.1 dev eth0  src 192.168.10.202
        cache <redirected>

Its not clear to me what the netmask on eth0 is - is this a /16

(in which case both redirs are "good" as far as the receiver can tell)? Are the 2 gws also on a /16? or something longer?

Quoted 1 line

The sanity check against netmask looks trivial, so why it is not there?

According to rfc1812 (pg 82-84)

Routers MUST NOT generate a Redirect Message unless all the following conditions are met:

o The packet is being forwarded out the same physical interface that it was received from,

o The IP source address in the packet is on the same Logical IP (sub)network as the next-hop IP address, and

o The packet does not contain an IP source route option.

The second condition seems to have been violated by the router. I suppose it might not hurt if the receiver can do some sanity checking on the redirect but this might not eliminate every error, since it might not be possible to detect netmask mismatch in every case.

Hello.

I was hitting a strange problem when some internet hosts suddenly stops responding until I reboot. ping to these host gives "Destination Host Unreachable". After the initial confusion, I've finally got to
ip route get
and got something quite strange.

Do you have admin control over the ubuntu router? If yes, you might want to check the shared_media [#] setting on that router for the interfaces with overlapping subnets. (it is on by default, I would try turning it off).

AFAICT, the code does the right thing per rfc1812 when setting IPSKB_DOREDIRECT if shared_media is turned off.

Likely the router's side is doing the right thing, but of

Do you have admin control over the ubuntu router? If yes, you might want to check the shared_media [#] setting on that router for the interfaces with overlapping subnets. (it is on by default, I would try turning it off).

29.12.2015 18:22, Sowmini Varadhan пишет:

Quoted 4 lines

Do you have admin control over the ubuntu router? If yes, you might want to check the shared_media [#] setting on that router for the interfaces with overlapping subnets. (it is on by default, I would try turning it off).

That didn't help, problem re-appears.
Thanks anyway, looks like I am going to disable accept_redirects then. It seems buggy and obviously no one cares.

Quoted 5 lines

29.12.2015 18:22, Sowmini Varadhan пишет:

Quoted 4 lines

Do you have admin control over the ubuntu router? If yes, you might want to check the shared_media [#] setting on that router for the interfaces with overlapping subnets. (it is on by default, I would try turning it off).

Quoted 3 lines

That didn't help, problem re-appears.
Thanks anyway, looks like I am going to disable accept_redirects then. It seems buggy and obviously no one cares.

Obviously some people take vacations at this period of the year, and do stay away from netdev traffic.

29.12.2015 18:22, Sowmini Varadhan пишет:

Quoted 4 lines

Do you have admin control over the ubuntu router? If yes, you might want to check the shared_media [#] setting on that router for the interfaces with overlapping subnets. (it is on by default, I would try turning it off).

That didn't help, problem re-appears.

Quoted 6 lines

29.12.2015 18:22, Sowmini Varadhan пишет:

Quoted 4 lines

Do you have admin control over the ubuntu router? If yes, you might want to check the shared_media [#] setting on that router for the interfaces with overlapping subnets. (it is on by default, I would try turning it off).

That didn't help, problem re-appears.

the code that sets things up for redirect is this:

   if (out_dev == in_dev && err && IN_DEV_TX_REDIRECTS(out_dev) &&
             skb->protocol == htons(ETH_P_IP) &&
             (IN_DEV_SHARED_MEDIA(out_dev) ||
              inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res))))
                 IPCB(skb)->flags |= IPSKB_DOREDIRECT;

If you are still seeing the problematic redirect after disabling shared_media, then you would need to trace through inet_addr_onlink() to see why it was not returning false. As I said before, afaict from reading the code, inet_addr_onlink looks right. So there may be something unusual with your netmask config on in_dev/out_dev.

But even if the redirect is suppressed, sounds like the network/netmask config is sub-optimal, since each packet gets (needlessly?) sent up/down the router's in_dev/out_dev. That should be avoided, if possible.

Quoted 6 lines

29.12.2015 18:22, Sowmini Varadhan пишет:

Quoted 4 lines

Do you have admin control over the ubuntu router? If yes, you might want to check the shared_media [#] setting on that router for the interfaces with overlapping subnets. (it is on by default, I would try turning it off).

That didn't help, problem re-appears.

the code that sets things up for redirect is this:

Do you have admin control over the ubuntu router? If yes, you might want to check the shared_media [#] setting on that router for the interfaces with overlapping subnets. (it is on by default, I would try turning it off).

Updated testing results:
After I disabled shared_media not only for "all", but also for _all_ interfaces individually, the problem seem to have stopped. So thanks for these hints.
Now, as the media is actually really shared (same NIC/cable), I just wonder what's going on here.

And unfortunately we still don't know why these redirects are ever accepted...

Quoted 6 lines

Updated testing results:
After I disabled shared_media not only for "all", but also for _all_ interfaces individually, the problem seem to have stopped. So thanks for these hints.
Now, as the media is actually really shared (same NIC/cable), I just wonder what's going on here.

I dont know the history of the shared_media tunable (or the rationale behind the default) - I was just reading out the code - perhaps someone on the list who has the history can share the motivation behind this tunable.

Hello.

I was hitting a strange problem when some internet hosts suddenly stops responding until I reboot. ping to these host gives "Destination Host Unreachable". After the initial confusion, I've finally got to
ip route get
and got something quite strange.

Example for GOOD address (the one that I can ping):

ip route get 91.189.89.237
91.189.89.237 via 192.168.8.1 dev eth0 src 192.168.10.202
cache

Example for BAD address (the one that stopped responding):

ip route get 91.189.89.238
91.189.89.238 via 192.168.0.1 dev eth0 src 192.168.10.202
cache <redirected>

Quoted 19 lines · Stas Sergeev

Hello.

I was hitting a strange problem when some internet hosts suddenly stops responding until I reboot. ping to these host gives "Destination Host Unreachable". After the initial confusion, I've finally got to
ip route get
and got something quite strange.

Example for GOOD address (the one that I can ping):

ip route get 91.189.89.237
91.189.89.237 via 192.168.8.1 dev eth0 src 192.168.10.202
cache

Example for BAD address (the one that stopped responding):

Quoted 3 lines

ip route get 91.189.89.238
91.189.89.238 via 192.168.0.1 dev eth0 src 192.168.10.202
cache <redirected>

I tried to understand this thread and now wonder why this redirect route isn't there always. Can you please summarize again why this shouldn't happen? It looks totally fine to me from the configuration of your router and the subnet masks.

Quoted 20 lines · Stas Sergeev

Quoted 19 lines

Hello.

I was hitting a strange problem when some internet hosts suddenly stops responding until I reboot. ping to these host gives "Destination Host Unreachable". After the initial confusion, I've finally got to
ip route get
and got something quite strange.

Example for GOOD address (the one that I can ping):

ip route get 91.189.89.237
91.189.89.237 via 192.168.8.1 dev eth0 src 192.168.10.202
cache

Example for BAD address (the one that stopped responding):

Quoted 8 lines

Quoted 3 lines

ip route get 91.189.89.238
91.189.89.238 via 192.168.0.1 dev eth0 src 192.168.10.202
cache <redirected>

I tried to understand this thread and now wonder why this redirect route isn't there always. Can you please summarize again why this shouldn't happen? It looks totally fine to me from the configuration of your router and the subnet masks.

Just an addendum:

In IPv6 a redirect is seen as a notification telling hosts, this new address is on the same link as you. I think this semantic is the same for IPv4, so we are informing you that in essence you are getting a /32 route installed to your new interface and can do link layer resolving of the new host.

I do think this is valid and fine.

12.01.2016 18:52, Hannes Frederic Sowa пишет:

Quoted 32 lines · Hannes Frederic Sowa

Quoted 20 lines · Stas Sergeev

Quoted 19 lines

Hello.

I was hitting a strange problem when some internet hosts suddenly stops responding until I reboot. ping to these host gives "Destination Host Unreachable". After the initial confusion, I've finally got to
ip route get
and got something quite strange.

Example for GOOD address (the one that I can ping):

ip route get 91.189.89.237
91.189.89.237 via 192.168.8.1 dev eth0 src 192.168.10.202
cache

Example for BAD address (the one that stopped responding):

Quoted 8 lines

Quoted 3 lines

ip route get 91.189.89.238
91.189.89.238 via 192.168.0.1 dev eth0 src 192.168.10.202
cache <redirected>

I tried to understand this thread and now wonder why this redirect route isn't there always. Can you please summarize again why this shouldn't happen? It looks totally fine to me from the configuration of your router and the subnet masks.

Just an addendum:

Quoted 4 lines

In IPv6 a redirect is seen as a notification telling hosts, this new address is on the same link as you. I think this semantic is the same for IPv4, so we are informing you that in essence you are getting a /32 route installed to your new interface and can do link layer resolving of the new host.

I do think this is valid and fine.

You can't call "valid and fine" something that doesn't work, at first place. Why and where does it fail, was the subject of this thread.

If you think router did the right thing, then please explain the breakage from that point of view.

Quoted 36 lines

12.01.2016 18:52, Hannes Frederic Sowa пишет:

Quoted 35 lines · Hannes Frederic Sowa

Quoted 20 lines · Stas Sergeev

Quoted 19 lines

Hello.

I was hitting a strange problem when some internet hosts suddenly stops responding until I reboot. ping to these host gives "Destination Host Unreachable". After the initial confusion, I've finally got to
ip route get
and got something quite strange.

Example for GOOD address (the one that I can ping):

ip route get 91.189.89.237
91.189.89.237 via 192.168.8.1 dev eth0 src 192.168.10.202
cache

Example for BAD address (the one that stopped responding):

Quoted 8 lines

Quoted 3 lines

ip route get 91.189.89.238
91.189.89.238 via 192.168.0.1 dev eth0 src 192.168.10.202
cache <redirected>

I tried to understand this thread and now wonder why this redirect route isn't there always. Can you please summarize again why this shouldn't happen? It looks totally fine to me from the configuration of your router and the subnet masks.

Just an addendum:

In IPv6 a redirect is seen as a notification telling hosts, this new address is on the same link as you. I think this semantic is the same for IPv4, so we are informing you that in essence you are getting a /32 route installed to your new interface and can do link layer resolving of the new host.

Quoted 4 lines

Quoted 1 line

I do think this is valid and fine.

You can't call "valid and fine" something that doesn't work, at first place. Why and where does it fail, was the subject of this thread.

In terms of the shared media specification <https://tools.ietf.org/html/rfc1620> it is valid and fine.

You can also disable shared_media on the client and it won't accept such redirects anymore.

Quoted 2 lines

If you think router did the right thing, then please explain the breakage from that point of view.

Hope it makes sense.

12.01.2016 19:10, Hannes Frederic Sowa пишет:

Quoted 37 lines · Stas Sergeev

Quoted 36 lines

12.01.2016 18:52, Hannes Frederic Sowa пишет:

Quoted 35 lines · Hannes Frederic Sowa

Quoted 20 lines · Stas Sergeev

Quoted 19 lines

Hello.

I was hitting a strange problem when some internet hosts suddenly stops responding until I reboot. ping to these host gives "Destination Host Unreachable". After the initial confusion, I've finally got to
ip route get
and got something quite strange.

Example for GOOD address (the one that I can ping):

ip route get 91.189.89.237
91.189.89.237 via 192.168.8.1 dev eth0 src 192.168.10.202
cache

Example for BAD address (the one that stopped responding):

Quoted 8 lines

Quoted 3 lines

ip route get 91.189.89.238
91.189.89.238 via 192.168.0.1 dev eth0 src 192.168.10.202
cache <redirected>

I tried to understand this thread and now wonder why this redirect route isn't there always. Can you please summarize again why this shouldn't happen? It looks totally fine to me from the configuration of your router and the subnet masks.

Just an addendum:

In IPv6 a redirect is seen as a notification telling hosts, this new address is on the same link as you. I think this semantic is the same for IPv4, so we are informing you that in essence you are getting a /32 route installed to your new interface and can do link layer resolving of the new host.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

I do think this is valid and fine.

You can't call "valid and fine" something that doesn't work, at first place. Why and where does it fail, was the subject of this thread.

In terms of the shared media specification <https://tools.ietf.org/html/rfc1620> it is valid and fine.

Good luck sending users to RFC without giving any explanations. :) Well, yes, an interesting reading, but:
https://tools.ietf.org/html/rfc1812
---
Routers MUST NOT generate a Redirect Message unless all the following conditions are met:

o The packet is being forwarded out the same physical interface that it was received from,

o The IP source address in the packet is on the same Logical IP (sub)network as the next-hop IP address, and

o The packet does not contain an IP source route option.

The source address used in the ICMP Redirect MUST belong to the same logical (sub)net as the destination address.
---

Could you please explain why the above does not apply?

12.01.2016 19:42, Stas Sergeev пишет:

Quoted 45 lines

12.01.2016 19:10, Hannes Frederic Sowa пишет:

Quoted 37 lines · Stas Sergeev

Quoted 36 lines

12.01.2016 18:52, Hannes Frederic Sowa пишет:

Quoted 35 lines · Hannes Frederic Sowa

Quoted 20 lines · Stas Sergeev

Quoted 19 lines

Hello.

I was hitting a strange problem when some internet hosts suddenly stops responding until I reboot. ping to these host gives "Destination Host Unreachable". After the initial confusion, I've finally got to
ip route get
and got something quite strange.

Example for GOOD address (the one that I can ping):

ip route get 91.189.89.237
91.189.89.237 via 192.168.8.1 dev eth0 src 192.168.10.202
cache

Example for BAD address (the one that stopped responding):

Quoted 8 lines

Quoted 3 lines

ip route get 91.189.89.238
91.189.89.238 via 192.168.0.1 dev eth0 src 192.168.10.202
cache <redirected>

I tried to understand this thread and now wonder why this redirect route isn't there always. Can you please summarize again why this shouldn't happen? It looks totally fine to me from the configuration of your router and the subnet masks.

Just an addendum:

In IPv6 a redirect is seen as a notification telling hosts, this new address is on the same link as you. I think this semantic is the same for IPv4, so we are informing you that in essence you are getting a /32 route installed to your new interface and can do link layer resolving of the new host.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

I do think this is valid and fine.

You can't call "valid and fine" something that doesn't work, at first place. Why and where does it fail, was the subject of this thread.

In terms of the shared media specification <https://tools.ietf.org/html/rfc1620> it is valid and fine.

Good luck sending users to RFC without giving any explanations. :)

Quoted 12 lines

Well, yes, an interesting reading, but:
https://tools.ietf.org/html/rfc1812
---
Routers MUST NOT generate a Redirect Message unless all the following conditions are met:

o The packet is being forwarded out the same physical interface that it was received from,

o The IP source address in the packet is on the same Logical IP (sub)network as the next-hop IP address, and

Quoted 7 lines

o The packet does not contain an IP source route option.

The source address used in the ICMP Redirect MUST belong to the same logical (sub)net as the destination address.
---

Could you please explain why the above does not apply?

Also the rfc1620 you pointed, seems to be saying this:

A Redirect message SHOULD be silently discarded if the new router address it specifies is not on the same connected (sub-) net through which the Redirect arrived, or if the source of the Redirect is not the current first-hop router for the specified destination.

It seems, this is exactly the rule we were trying to find during the thread. And it seems violated, either. Unless I am mis-interpreting it, of course.

Quoted 46 lines

12.01.2016 19:42, Stas Sergeev пишет:

Quoted 45 lines

12.01.2016 19:10, Hannes Frederic Sowa пишет:

Quoted 37 lines · Stas Sergeev

Quoted 36 lines

12.01.2016 18:52, Hannes Frederic Sowa пишет:

Quoted 35 lines · Hannes Frederic Sowa

Quoted 20 lines · Stas Sergeev

Quoted 19 lines

Hello.

I was hitting a strange problem when some internet hosts suddenly stops responding until I reboot. ping to these host gives "Destination Host Unreachable". After the initial confusion, I've finally got to
ip route get
and got something quite strange.

Example for GOOD address (the one that I can ping):

ip route get 91.189.89.237
91.189.89.237 via 192.168.8.1 dev eth0 src 192.168.10.202
cache

Example for BAD address (the one that stopped responding):

Quoted 8 lines

Quoted 3 lines

ip route get 91.189.89.238
91.189.89.238 via 192.168.0.1 dev eth0 src 192.168.10.202
cache <redirected>

I tried to understand this thread and now wonder why this redirect route isn't there always. Can you please summarize again why this shouldn't happen? It looks totally fine to me from the configuration of your router and the subnet masks.

Just an addendum:

In IPv6 a redirect is seen as a notification telling hosts, this new address is on the same link as you. I think this semantic is the same for IPv4, so we are informing you that in essence you are getting a /32 route installed to your new interface and can do link layer resolving of the new host.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

I do think this is valid and fine.

You can't call "valid and fine" something that doesn't work, at first place. Why and where does it fail, was the subject of this thread.

In terms of the shared media specification <https://tools.ietf.org/html/rfc1620> it is valid and fine.

Good luck sending users to RFC without giving any explanations. :)

It explains how and what extensions need to be added to an ip routing/host device to deal better with shared media.

Quoted 27 lines

Quoted 12 lines

Well, yes, an interesting reading, but:
https://tools.ietf.org/html/rfc1812
---
Routers MUST NOT generate a Redirect Message unless all the following conditions are met:

o The packet is being forwarded out the same physical interface that it was received from,

o The IP source address in the packet is on the same Logical IP (sub)network as the next-hop IP address, and

Quoted 7 lines

o The packet does not contain an IP source route option.

The source address used in the ICMP Redirect MUST belong to the same logical (sub)net as the destination address.
---

Could you please explain why the above does not apply?

Also the rfc1620 you pointed, seems to be saying this:

A Redirect message SHOULD be silently discarded if the new router address it specifies is not on the same connected (sub-) net through which the Redirect arrived, or if the source of the Redirect is not the current first-hop router for the specified destination.

Quoted 3 lines

It seems, this is exactly the rule we were trying to find during the thread. And it seems violated, either. Unless I am mis-interpreting it, of course.

If you read on you will read that with shared_media this exact clause (the first of those) is not in effect any more.

I don't know why shared_media=1 is the default in Linux, this decision was made long before I joined here. Anyway, with shared_media=1 this is absolutely the required behavior.

12.01.2016 20:06, Hannes Frederic Sowa пишет:

Quoted 10 lines · Stas Sergeev

Quoted 9 lines

12.01.2016 19:42, Stas Sergeev пишет:
Also the rfc1620 you pointed, seems to be saying this:

A Redirect message SHOULD be silently discarded if the new router address it specifies is not on the same connected (sub-) net through which the Redirect arrived, or if the source of the Redirect is not the current first-hop router for the specified destination.

Quoted 5 lines

Quoted 3 lines

It seems, this is exactly the rule we were trying to find during the thread. And it seems violated, either. Unless I am mis-interpreting it, of course.

If you read on you will read that with shared_media this exact clause (the first of those) is not in effect any more.

OK. But how to get such a redirect to work, if (checked with tcpdump) the packets do not even go to eth0, but to "lo"?

And how to deal with the above quote from rfc1812?

Quoted 1 line

I don't know why shared_media=1 is the default in Linux, this decision was made long before I joined here. Anyway, with shared_media=1 this is absolutely the required behavior.

Then it should work. How? :)

Quoted 15 lines

12.01.2016 20:06, Hannes Frederic Sowa пишет:

Quoted 14 lines · Stas Sergeev

Quoted 12 lines

12.01.2016 19:42, Stas Sergeev пишет:
Also the rfc1620 you pointed, seems to be saying this:

A Redirect message SHOULD be silently discarded if the new router address it specifies is not on the same connected (sub-) net through which the Redirect arrived, or if the source of the Redirect is not the current first-hop router for the specified destination.

It seems, this is exactly the rule we were trying to find during the thread. And it seems violated, either. Unless I am mis-interpreting it, of course.

Quoted 3 lines

Quoted 1 line

If you read on you will read that with shared_media this exact clause (the first of those) is not in effect any more.

OK. But how to get such a redirect to work, if (checked with tcpdump) the packets do not even go to eth0, but to "lo"?

I don't know, the router must be on the same shared medium. I guess physical reconfiguration is required?

Quoted 2 lines

Quoted 1 line

I don't know why shared_media=1 is the default in Linux, this decision was made long before I joined here. Anyway, with shared_media=1 this is absolutely the required behavior.

Then it should work. How? :)

What should work? Sorry, I can't follow you. Everything looks fine to me.

12.01.2016 20:26, Hannes Frederic Sowa пишет:

Quoted 16 lines · Stas Sergeev

Quoted 15 lines

12.01.2016 20:06, Hannes Frederic Sowa пишет:

Quoted 14 lines · Stas Sergeev

Quoted 12 lines

12.01.2016 19:42, Stas Sergeev пишет:
Also the rfc1620 you pointed, seems to be saying this:

A Redirect message SHOULD be silently discarded if the new router address it specifies is not on the same connected (sub-) net through which the Redirect arrived, or if the source of the Redirect is not the current first-hop router for the specified destination.

It seems, this is exactly the rule we were trying to find during the thread. And it seems violated, either. Unless I am mis-interpreting it, of course.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

If you read on you will read that with shared_media this exact clause (the first of those) is not in effect any more.

OK. But how to get such a redirect to work, if (checked with tcpdump) the packets do not even go to eth0, but to "lo"?

I don't know, the router must be on the same shared medium. I guess physical reconfiguration is required?

It is same.
Router 192.168.8.1 has just one ethernet port.
And even on the 192.168.10.202 node I can do:

# arp -a |grep "0.1"
? (192.168.0.1) at 14:d6:4d:1c:97:3d [ether] on eth0
So even 0.1 is about to be reachable.
Still nothing works.
Should it work if 192.168.0.1 router, to which 8.1 redirects,
has shared_media disabled?

Quoted 29 lines

12.01.2016 20:26, Hannes Frederic Sowa пишет:

Quoted 20 lines · Stas Sergeev

Quoted 19 lines

12.01.2016 20:06, Hannes Frederic Sowa пишет:

Quoted 18 lines · Stas Sergeev

Quoted 16 lines

12.01.2016 19:42, Stas Sergeev пишет:
Also the rfc1620 you pointed, seems to be saying this:

A Redirect message SHOULD be silently
discarded if the
new router address it specifies is not on the
same
connected (sub-) net through which the
Redirect arrived,
or if the source of the Redirect is not the
current
first-hop router for the specified destination.

It seems, this is exactly the rule we were trying to find during the thread. And it seems violated, either. Unless I am mis-interpreting it, of course.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

If you read on you will read that with shared_media this exact clause (the first of those) is not in effect any more.

OK. But how to get such a redirect to work, if (checked with tcpdump) the packets do not even go to eth0, but to "lo"?

I don't know, the router must be on the same shared medium. I guess physical reconfiguration is required?

It is same.
Router 192.168.8.1 has just one ethernet port.
And even on the 192.168.10.202 node I can do:

Quoted 6 lines

# arp -a |grep "0.1"
? (192.168.0.1) at 14:d6:4d:1c:97:3d [ether] on eth0
So even 0.1 is about to be reachable.
Still nothing works.
Should it work if 192.168.0.1 router, to which 8.1 redirects,
has shared_media disabled?

Can you check with tcpdump?

ping requires the router to also find a correct way back, so packet can get stuck at a lot of places. Also uRPF is maybe active which kind of defeats shared_media and please check netfilter.

12.01.2016 20:47, Hannes Frederic Sowa пишет:

Quoted 39 lines · Stas Sergeev

Quoted 37 lines

12.01.2016 20:26, Hannes Frederic Sowa пишет:

Quoted 20 lines · Stas Sergeev

Quoted 19 lines

12.01.2016 20:06, Hannes Frederic Sowa пишет:

Quoted 18 lines · Stas Sergeev

Quoted 16 lines

12.01.2016 19:42, Stas Sergeev пишет:
Also the rfc1620 you pointed, seems to be saying this:

A Redirect message SHOULD be silently
discarded if the
new router address it specifies is not on the
same
connected (sub-) net through which the
Redirect arrived,
or if the source of the Redirect is not the
current
first-hop router for the specified destination.

It seems, this is exactly the rule we were trying to find during the thread. And it seems violated, either. Unless I am mis-interpreting it, of course.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

If you read on you will read that with shared_media this exact clause (the first of those) is not in effect any more.

OK. But how to get such a redirect to work, if (checked with tcpdump) the packets do not even go to eth0, but to "lo"?

I don't know, the router must be on the same shared medium. I guess physical reconfiguration is required?

It is same.
Router 192.168.8.1 has just one ethernet port.
And even on the 192.168.10.202 node I can do:

# arp -a |grep "0.1"
? (192.168.0.1) at 14:d6:4d:1c:97:3d [ether] on eth0
So even 0.1 is about to be reachable.
Still nothing works.
Should it work if 192.168.0.1 router, to which 8.1 redirects,
has shared_media disabled?

Quoted 1 line

Can you check with tcpdump?

That's what I already did.
I monitored on 8.1 router and on the node itself, and my conclusion was that the packets do not even reach the eth0 interface. Instead I captured them on "lo" interface, so I assumed such route is completely broken.

If it is not - how can I even see that it exist? How to list these redirect routes?

I'd like to do some investigations, but this looks no more than a black magic without a proper support from tools, proper documentation, etc.

And I suspect that shared_media is disabled on a 0.1 router, so I wonder if this can work at all, even if the node is cured to do the right thing with those redirects. In a nearby message David Miller says:

---

2) increasing the chance of successful communication with peers

---
If this can't work right when one of the gateways has shared_media disabled, then this rule is clearly violated.

Quoted 3 lines

ping requires the router to also find a correct way back, so packet can get stuck at a lot of places. Also uRPF is maybe active which kind of defeats shared_media and please check netfilter.

I am pretty sure the node has a default ubuntu without any special network tweaks, but I'll double-check.

Hi,

Quoted 41 lines · Stas Sergeev

12.01.2016 20:47, Hannes Frederic Sowa пишет:

Quoted 40 lines · Stas Sergeev

Quoted 31 lines

12.01.2016 20:26, Hannes Frederic Sowa пишет:

Quoted 20 lines · Stas Sergeev

Quoted 19 lines

12.01.2016 20:06, Hannes Frederic Sowa пишет:

Quoted 18 lines · Stas Sergeev

Quoted 16 lines

12.01.2016 19:42, Stas Sergeev пишет:
Also the rfc1620 you pointed, seems to be saying this:

A Redirect message SHOULD be silently
discarded if the
new router address it specifies is not on the
same
connected (sub-) net through which the
Redirect arrived,
or if the source of the Redirect is not the
current
first-hop router for the specified destination.

It seems, this is exactly the rule we were trying to find during the thread. And it seems violated, either. Unless I am mis-interpreting it, of course.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

If you read on you will read that with shared_media this exact clause (the first of those) is not in effect any more.

OK. But how to get such a redirect to work, if (checked with tcpdump) the packets do not even go to eth0, but to "lo"?

I don't know, the router must be on the same shared medium. I guess physical reconfiguration is required?

It is same.
Router 192.168.8.1 has just one ethernet port.
And even on the 192.168.10.202 node I can do:

Quoted 6 lines

# arp -a |grep "0.1"
? (192.168.0.1) at 14:d6:4d:1c:97:3d [ether] on eth0
So even 0.1 is about to be reachable.
Still nothing works.
Should it work if 192.168.0.1 router, to which 8.1 redirects,
has shared_media disabled?

Can you check with tcpdump?

Quoted 6 lines

That's what I already did.
I monitored on 8.1 router and on the node itself, and my conclusion was that the packets do not even reach the eth0 interface. Instead I captured them on "lo" interface, so I assumed such route is completely broken.

I didn't check a full featured setup but just did some dirty testing with namespaces and I had correct arp request for the now to be assumed on-link router on the external veth.

Quoted 2 lines

If it is not - how can I even see that it exist? How to list these redirect routes?

Yeah, that might be a minor issue. The rt_cache procfs files are empty since the deletion of the cache and we probably don't have an interface for next hop exceptions, I consider this todo. :) ip route get is your only hope right now.

Anyway, seems like there are problems with redirect timeout somehow. I am investigating this.

Quoted 3 lines

I'd like to do some investigations, but this looks no more than a black magic without a proper support from tools, proper documentation, etc.

Hmm, so far I think shared_media is behaving like it should,

besides maybe it shouldn't be the default setting. Maybe someone who can remember why it is default could chime in?

Quoted 4 lines

And I suspect that shared_media is disabled on a 0.1 router, so I wonder if this can work at all, even if the node is cured to do the right thing with those redirects. In a nearby message David Miller says:

Default is that shared_media is enabled,

so the chances are relatively high that it is enabled if it is not turned off.

Quoted 7 lines

---

2) increasing the chance of successful communication with peers

---
If this can't work right when one of the gateways has shared_media disabled, then this rule is clearly violated.

It can work right and I think the RFC actually gives examples where it is very useful. Also IPv6 adapts it as the default, so it might make sense to have it as default.

I still consider something broken in your network setup, maybe.

Quoted 5 lines

Quoted 3 lines

ping requires the router to also find a correct way back, so packet can get stuck at a lot of places. Also uRPF is maybe active which kind of defeats shared_media and please check netfilter.

I am pretty sure the node has a default ubuntu without any special network tweaks, but I'll double-check.

Please do that. Thanks!

13.01.2016 01:26, Hannes Frederic Sowa пишет:

Quoted 3 lines

I didn't check a full featured setup but just did some dirty testing with namespaces and I had correct arp request for the now to be assumed on-link router on the external veth.

I haven't checked anything with arp.
I set up tcpdump to only capture icmp.
What would you like me to check, could you please
give the detailed instructions?

Quoted 15 lines

Quoted 2 lines

If it is not - how can I even see that it exist? How to list these redirect routes?

Yeah, that might be a minor issue. The rt_cache procfs files are empty since the deletion of the cache and we probably don't have an interface for next hop exceptions, I consider this todo. :) ip route get is your only hope right now.

Anyway, seems like there are problems with redirect timeout somehow. I am investigating this.

Quoted 3 lines

I'd like to do some investigations, but this looks no more than a black magic without a proper support from tools, proper documentation, etc.

Quoted 1 line

Hmm, so far I think shared_media is behaving like it should,

No, unless you correct the documentation:
https://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/theconfvariables.html

It says not what you say.
So this feature is essentially poorly (or wrongly) documented.

Quoted 8 lines

besides maybe it shouldn't be the default setting. Maybe someone who can remember why it is default could chime in?

Quoted 4 lines

And I suspect that shared_media is disabled on a 0.1 router, so I wonder if this can work at all, even if the node is cured to do the right thing with those redirects. In a nearby message David Miller says:

Quoted 1 line

Default is that shared_media is enabled,

On what OS, and since what version?

Quoted 2 lines

so the chances are relatively high that it is enabled if it is not turned off.

I don't even know what is there in a 0.1 router - maybe windows95, who knows. You can't assume the latest linux kernel is everywhere.

Quoted 17 lines

Quoted 7 lines

---

2) increasing the chance of successful communication with peers

---
If this can't work right when one of the gateways has shared_media disabled, then this rule is clearly violated.

It can work right and I think the RFC actually gives examples where it is very useful. Also IPv6 adapts it as the default, so it might make sense to have it as default.

I still consider something broken in your network setup, maybe.

Quoted 3 lines

Quoted 3 lines

ping requires the router to also find a correct way back, so packet can get stuck at a lot of places. Also uRPF is maybe active which kind of defeats shared_media and please check netfilter.

Quoted 4 lines

Quoted 2 lines

I am pretty sure the node has a default ubuntu without any special network tweaks, but I'll double-check.

Please do that. Thanks!

OK but please make it clear what should I check. iptables do not seem to be in the game, what else to check?

Hi,

Quoted 4 lines · Stas Sergeev

13.01.2016 01:26, Hannes Frederic Sowa пишет:

Quoted 3 lines

I didn't check a full featured setup but just did some dirty testing with namespaces and I had correct arp request for the now to be assumed on-link router on the external veth.

Quoted 4 lines

I haven't checked anything with arp.
I set up tcpdump to only capture icmp.
What would you like me to check, could you please
give the detailed instructions?

Check simply for arp traffic on the interface. arp requests should leave your client and ask directly for the new router you got as next-hop. If it does not answer, there is the problem.

Quoted 19 lines

Quoted 8 lines

Quoted 2 lines

If it is not - how can I even see that it exist? How to list these redirect routes?

Yeah, that might be a minor issue. The rt_cache procfs files are empty since the deletion of the cache and we probably don't have an interface for next hop exceptions, I consider this todo. :) ip route get is your only hope right now.

Quoted 8 lines

Anyway, seems like there are problems with redirect timeout somehow. I am investigating this.

Quoted 3 lines

I'd like to do some investigations, but this looks no more than a black magic without a proper support from tools, proper documentation, etc.

Hmm, so far I think shared_media is behaving like it should,

No, unless you correct the documentation:
https://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/theconfvariables.html

Quoted 2 lines

It says not what you say.
So this feature is essentially poorly (or wrongly) documented.

I am sorry, but I have no access to this website. I just grepped around in the Documentation/ directory of the kernel:
<https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/ip-sysctl.txt?id=refs/tags/v4.4#n1014>

It is correctly documented

Quoted 9 lines

Quoted 9 lines

besides maybe it shouldn't be the default setting. Maybe someone who can remember why it is default could chime in?

Quoted 4 lines

And I suspect that shared_media is disabled on a 0.1 router, so I wonder if this can work at all, even if the node is cured to do the right thing with those redirects. In a nearby message David Miller says:

Default is that shared_media is enabled,

Quoted 6 lines

On what OS, and since what version?

Quoted 2 lines

so the chances are relatively high that it is enabled if it is not turned off.

I don't even know what is there in a 0.1 router - maybe windows95, who knows. You can't assume the latest linux kernel is everywhere.

Looking into the kernel cvs history the change was done in 2000(!). Would be pretty strange to find such an old kernel there.

If it would be 0 the rfc1812 applies and
should stop servers to send such redirects and clients to accept those.

Quoted 17 lines

Hello.

I was hitting a strange problem when some internet hosts suddenly stops responding until I reboot. ping to these host gives "Destination Host Unreachable". After the initial confusion, I've finally got to
ip route get
and got something quite strange.

Example for GOOD address (the one that I can ping):

ip route get 91.189.89.237
91.189.89.237 via 192.168.8.1 dev eth0 src 192.168.10.202
cache

Quoted 5 lines

Example for BAD address (the one that stopped responding):

ip route get 91.189.89.238
91.189.89.238 via 192.168.0.1 dev eth0 src 192.168.10.202
cache <redirected>

I tried to understand this thread and now wonder why this redirect route isn't there always. Can you please summarize again why this shouldn't happen? It looks totally fine to me from the configuration of your router and the subnet masks.