LARTC - Dec 2001 - bug fixed: equal cost multipath shows first hop as dead

This had been bugging me for a while:

  # ip ro add dev eth0 default nexthop via 10.0.0.1 dev eth0 nexthop via
    10.0.0.202 dev eth0
  # ip ro ls
  10.0.0.0/8 dev eth0  proto kernel  scope link  src 10.0.0.11
  default
> 	nexthop via 10.0.0.1  dev eth0 weight 1 dead
  	nexthop via 10.0.0.202  dev eth0 weight 1

Some people did not see this bug, other people did. Note how the first
nexthop is ''dead'', even though it isn''t.

It turns out that this is due to a bug in ''ip'' which only
occurs with some
versions of gcc, amongst which gcc-2.95.

I posted a detailed bugreport, and our great friend Julian Anastasov replied
within minutes with this patch:

--- iproute2/ip/iproute.c.orig	Mon Aug  6 03:31:52 2001
+++ iproute2/ip/iproute.c	Thu Dec 20 13:14:06 2001
@@ -620,6 +620,8 @@
 		}
 		rtnh->rtnh_len = sizeof(*rtnh);
 		rtnh->rtnh_ifindex = 0;
+		rtnh->rtnh_flags = 0;
+		rtnh->rtnh_hops = 0;
 		rta->rta_len += rtnh->rtnh_len;
 		parse_one_nh(rta, rtnh, &argc, &argv);
 		rtnh = RTNH_NEXT(rtnh);

And then ''nexthop'' works as it should. Note that this does not
mean that it
does roundrobin over your nexthops. The routecache prevents this. If anybody
is a ''nexthop'' expert, please help me write a section on it.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc

Hello,

On Thu, 20 Dec 2001, bert hubert wrote:
> And then ''nexthop'' works as it should. Note that this
does not mean that it
> does roundrobin over your nexthops. The routecache prevents this. If
anybody
	Yes, the route cache keeps the both ends connected through
one path. But this is disturbed from changes in the TOS, related ICMPs
are not aware what is going on, etc. and we end up with a packets from
or related to connection spread on many paths. So, it is a problem to
route all packets from one connection via multipath route. This is why
we sometimes use it only for the first packet. Hm, why the "TOS as routing
key" is not an option?
> Regards,
>
> bert
Regards

--
Julian Anastasov <ja@ssi.bg>