I have weird problem. I have some of the servers on RHEL-7.2, in that I am not able to add the route.

This route addition is something, which I have done thousand of time. The error I am getting is NO-Route to host which is kind of strange.

I am getting following error in the route addition #

route -A inet6 add 1203:900:223:3524:21::/112 gw 1203:270:713:3214:34::1
SIOCADDRT: No route to host

Following is the output of my device#

[root@localhost ~]# ifconfig eth2

eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet6 1203:270:713:3214:34::12  prefixlen 112  scopeid 0x0<global>
        inet6 fe80::250:56ff:feaf:3ab7  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:af:3a:b7  txqueuelen 1000  (Ethernet)
        RX packets 23405  bytes 1429434 (1.3 MiB)
        RX errors 0  dropped 22220  overruns 0  frame 0
        TX packets 4129  bytes 352750 (344.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Gateway IPs are reachable #

[root@localhost ~]# ping6 1203:270:713:3214:34::1
PING 1203:270:713:3214:34::1(1203:270:713:3214:34::1) 56 data bytes

64 bytes from 1203:270:713:3214:34::1: icmp_seq=1 ttl=254 time=0.678 ms

64 bytes from 1203:270:713:3214:34::1: icmp_seq=2 ttl=254 time=0.576 ms

--- 2405:200:613:3214:34::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.576/0.627/0.678/0.051 ms

device interface is up and running ##

[root@localhost ~]# ethtool eth2

Settings for eth2:

    Supported ports: [ TP ]
    Supported link modes:   1000baseT/Full 
    Supported pause frame use: No
    Supports auto-negotiation: No
    Advertised link modes:  Not reported
    Advertised pause frame use: No
    Advertised auto-negotiation: No
    Speed: 10000Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: off
    MDI-X: Unknown
    Supports Wake-on: uag
    Wake-on: d
    Link detected: yes

Searched a lot on this topic. Not able to find the resolution ROUTE-ADDITION-FAILURE. Nothing seems to be relevant on this topic. This issue is coming only to some of RHEL, not on all the machines.

In case, someone have seen this issue somewhere. Please respond, would be really helpful.

  • 1
    It's very difficult to figure out what's going on, because you have used fake information. Please use either the real IPv6 addresses, or RFC 3849 example addresses if you must. – Michael Hampton May 23 '18 at 17:24
  • @MichaelHampton : Before sharing the inputs, I have changed 1st-3 Octets, because of IP-policy. Rest of things are in place. First 3 octets , you can assume any value. Problem is simple which is addition of route is failing. – Abhishek May 23 '18 at 18:42
  • Did you use /112 prefixes before? Theoretically the solicited multicast address uses the 24 lower bits. – Gerrit May 23 '18 at 18:42
  • I indeed added /112 prefix. Same route addition command is working on 50 other server machines. It is only failing on this once. – Abhishek May 23 '18 at 18:45
  • Does ip -6 route add .. have similar problems? – Gerrit May 23 '18 at 18:56

There is in a recent kernel as far as I can see, only one point that you can get EHOSTUNREACH on an ipv6 route addition.


            /* IPv6 strictly inhibits using not link-local
               addresses as nexthop address.
               Otherwise, router will not able to send redirects.
               It is very good, but in some (rare!) circumstances
               (SIT, PtP, NBMA NOARP links) it is handy to allow
               some exceptions. --ANK

The exception is, there must ALREADY be an ipv6 route to the gateway.

grt = rt6_lookup(net, gw_addr, NULL, cfg->fc_ifindex, 1);

This line above MUST succeed.

So, in all likelihood the situation that is different on this host, is that it didn't already have a nexthop configured by a router advertisement. The gateway is still on-link as determined by prefix, so it can be reached by ping, but it is not automatically already a route, and thus not a guarantee that the rt6_lookup will be succesful.

  • Thanks, I have been working with Router-guy already. He is kind of not agreeing on the same. But my point is , if look-up is failing, I must be seeing some message going out in tcpdump. I am not seeing that either. Anyway, let me work with route-guy once and get the configuration checked for all the ports. – Abhishek May 24 '18 at 2:13
  • What does ip -6 r show? – Gerrit May 24 '18 at 6:48
  • xxxx:xxx:xxx:3524:21::10 via fe80::222:bdff:fef8:19ff dev eth2 metric 0 cache hoplimit 64 xxxx:xxx:xxx:3524:21::11 via fe80::222:bdff:fef8:19ff dev eth2 metric 0 cache hoplimit 64 xxxx:xxx:xxx:3524:21::12 via fe80::222:bdff:fef8:19ff dev eth2 metric 0 cache hoplimit 64 These routes are not present in working machine. – Abhishek May 24 '18 at 19:55
  • So you are not seeing a default route. Like this: default via fe80::aaaa:bbbb:cccc:dddd dev ethx proto ra metric 1024 expires 1693sec hoplimit 64 pref medium. That explains why the kernel at this point refuses to add a global unicast nexthop, because there is no existing route to that address (xxxx:xxx:xxx:3214:34::1). Which is independent from it being on-link and pingable. fe80::222:bdff:fef8:19ff should be a valid nexthop for the default route. – Gerrit May 24 '18 at 21:20
  • I didn’t mention, but I am seeing default route advertisement. And default-route like that is added. – Abhishek May 25 '18 at 6:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.