From: Markus Stenberg <hidden> Date: 2012-09-06 10:10:04
~ # ip route add throw 1.2.3.4
~ # ip -6 route add throw ::1.2.3.4
RTNETLINK answers: No such device
~ # ip route add blackhole 1.2.3.5
~ # ip -6 route add blackhole ::1.2.3.5
RTNETLINK answers: No such device
~ #
The reason for this is in net/ipv6/route.c - ipv6_route_add:
Eventually code winds up at this (1423 line in 3.5.3):
err = -ENODEV;
if (!dev)
goto out;
and poof, ENODEV.
Is there some reason for this? Or should I write a patch?
Or does someone else want to? Support for dev=NULL
elsewhere in the code seems to be ok.
Based on quick googling I'm not the first one to have encountered this.
Cheers,
-Markus
From: Eric Dumazet <hidden> Date: 2012-09-06 10:35:09
On Thu, 2012-09-06 at 10:02 +0000, Markus Stenberg wrote:
~ # ip route add throw 1.2.3.4
~ # ip -6 route add throw ::1.2.3.4
RTNETLINK answers: No such device
~ # ip route add blackhole 1.2.3.5
~ # ip -6 route add blackhole ::1.2.3.5
RTNETLINK answers: No such device
~ #
The reason for this is in net/ipv6/route.c - ipv6_route_add:
Eventually code winds up at this (1423 line in 3.5.3):
err = -ENODEV;
if (!dev)
goto out;
and poof, ENODEV.
Is there some reason for this? Or should I write a patch?
Or does someone else want to? Support for dev=NULL
elsewhere in the code seems to be ok.
Based on quick googling I'm not the first one to have encountered this.
Ah, cool, teaches me to refresh my git trees before posting ;-)
Nicolas, want to update for that too or will I?
Throw is useful in various cases (it is RTN_THROW / -EAGAIN).
Cheers,
-Markus
From: Nicolas Dichtel <hidden> Date: 2012-09-06 13:51:02
It's the same problem that previous fix about blackhole and prohibit routes.
When adding a throw route, it was handled like a classic route.
Moreover, it was only possible to add this kind of routes by specifying
an interface.
Before the patch:
$ ip route add throw 2001::2/128
RTNETLINK answers: No such device
$ ip route add throw 2001::2/128 dev eth0
$ ip -6 route | grep 2001::2
2001::2 dev eth0 metric 1024
After:
$ ip route add throw 2001::2/128
$ ip -6 route | grep 2001::2
throw 2001::2 dev lo metric 1024 error -11
Reported-by: Markus Stenberg <redacted>
Signed-off-by: Nicolas Dichtel <redacted>
---
net/ipv6/route.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
@@ -2412,6 +2416,9 @@ static int rt6_fill_node(struct net *net,case-EACCES:rtm->rtm_type=RTN_PROHIBIT;break;+case-EAGAIN:+rtm->rtm_type=RTN_THROW;+break;default:rtm->rtm_type=RTN_UNREACHABLE;break;
From: Eric Dumazet <hidden> Date: 2012-09-06 13:58:29
On Thu, 2012-09-06 at 11:53 -0400, Nicolas Dichtel wrote:
It's the same problem that previous fix about blackhole and prohibit routes.
When adding a throw route, it was handled like a classic route.
Moreover, it was only possible to add this kind of routes by specifying
an interface.
Before the patch:
$ ip route add throw 2001::2/128
RTNETLINK answers: No such device
$ ip route add throw 2001::2/128 dev eth0
$ ip -6 route | grep 2001::2
2001::2 dev eth0 metric 1024
After:
$ ip route add throw 2001::2/128
$ ip -6 route | grep 2001::2
throw 2001::2 dev lo metric 1024 error -11
Reported-by: Markus Stenberg <redacted>
Signed-off-by: Nicolas Dichtel <redacted>
---
net/ipv6/route.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
Acked-by: Eric Dumazet <edumazet@google.com>
Thanks Nicolas
It's the same problem that previous fix about blackhole and prohibit routes.
When adding a throw route, it was handled like a classic route.
Moreover, it was only possible to add this kind of routes by specifying
an interface.
Before the patch:
$ ip route add throw 2001::2/128
RTNETLINK answers: No such device
$ ip route add throw 2001::2/128 dev eth0
$ ip -6 route | grep 2001::2
2001::2 dev eth0 metric 1024
After:
$ ip route add throw 2001::2/128
$ ip -6 route | grep 2001::2
throw 2001::2 dev lo metric 1024 error -11
Reported-by: Markus Stenberg <redacted>
Signed-off-by: Nicolas Dichtel <redacted>
Applied, thanks.
See how easy this was to implement via ->rtm_type? :-)
It's the same problem that previous fix about blackhole and prohibit routes.
When adding a throw route, it was handled like a classic route.
Moreover, it was only possible to add this kind of routes by specifying
an interface.
Before the patch:
$ ip route add throw 2001::2/128
RTNETLINK answers: No such device
$ ip route add throw 2001::2/128 dev eth0
$ ip -6 route | grep 2001::2
2001::2 dev eth0 metric 1024
After:
$ ip route add throw 2001::2/128
$ ip -6 route | grep 2001::2
throw 2001::2 dev lo metric 1024 error -11
Reported-by: Markus Stenberg <redacted>
Signed-off-by: Nicolas Dichtel <redacted>
Applied, thanks.
See how easy this was to implement via ->rtm_type? :-)
It's the same problem that previous fix about blackhole and prohibit routes.
When adding a throw route, it was handled like a classic route.
Moreover, it was only possible to add this kind of routes by specifying
an interface.
Before the patch:
$ ip route add throw 2001::2/128
RTNETLINK answers: No such device
$ ip route add throw 2001::2/128 dev eth0
$ ip -6 route | grep 2001::2
2001::2 dev eth0 metric 1024
After:
$ ip route add throw 2001::2/128
$ ip -6 route | grep 2001::2
throw 2001::2 dev lo metric 1024 error -11
Reported-by: Markus Stenberg <markus.stenberg <at> iki.fi>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel <at> 6wind.com>
Applied, thanks.
Although 'ip -6 route show' now reports a "throw" instead of an "unreachable"
route the behavior of a configured IPv6 "throw" route still seems incorrect and
similar to that of an "unreachable" route!
I've tested with kernel 3.7.4 which includes this patch:
http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=commitdiff;h=ef2c7d7b59708d54213c7556a82d14de9a7e4475
An example scenario using a dedicated routing table (IMHO the main use case for
throw routes) is given below...
greetings
/axel
The following scenario shows an example:
computer 1001 and 1002 connected via ethernet eth2
computer 1002 has 1001:2::2/64 on eth2
Now at computer 1001:
root@mlc1001:~# ping6 1001:2::2 -c 1
connect: Network is unreachable
root@mlc1001:~# ip a add 1001:2::1/64 dev eth2
root@mlc1001:~# ip -6 rule add from all lookup 10 pref 1000
root@mlc1001:~# ip -6 rule
0: from all lookup local
1000: from all lookup 10
32766: from all lookup main
root@mlc1001:~# ip -6 route list table 10
root@mlc1001:~# ping6 1001:2::2 -c 1
PING 1001:2::2(1001:2::2) 56 data bytes
64 bytes from 1001:2::2: icmp_seq=1 ttl=64 time=0.263 ms
--- 1001:2::2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.263/0.263/0.263/0.000 ms
root@mlc1001:~# ip -6 route add throw 1001:2::/64 table 10
root@mlc1001:~# ip -6 route list table 10
throw 1001:2::/64 dev lo metric 1024 error -11
root@mlc1001:~# ping6 1001:2::2 -c 1
connect: Resource temporarily unavailable
# Although the destination lookup should only be thrown for table 10
# and continue on the main table where a valid local route exists
# it fails. For remote throw routes the error says something like:
# From 1001:2::2 icmp_seq=1 Destination unreachable: No route
# Removing the throw route again it works again...
root@mlc1001:~# ip -6 r
1001:2::/64 dev eth2 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth1 proto kernel metric 256
fe80::/64 dev eth2 proto kernel metric 256
root@mlc1001:~# ip -6 route del throw 1001:2::/64 table 10
root@mlc1001:~# ping6 1001:2::2 -c 1
PING 1001:2::2(1001:2::2) 56 data bytes
64 bytes from 1001:2::2: icmp_seq=1 ttl=64 time=0.264 ms
--- 1001:2::2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.264/0.264/0.264/0.000 ms
root@mlc1001:~# ip -6 r
1001:2::2 via 1001:2::2 dev eth2 metric 0
cache
1001:2::/64 dev eth2 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth1 proto kernel metric 256
fe80::/64 dev eth2 proto kernel metric 256
root@mlc1001:~#