Hello Stephen and netdev people!

Currently you can configure "equalize" and it looks all fine and dandy.
The kernel has the interface defined, but apparently there's never actually
been any implementation for it (only a never merged patch in the 2.4 era).

I'm suggesting to drop the code to give any potential users of this feature
the benefit of receiving a proper error message. I see it unlikely that
this will be implemented in the near future, but if it ever happens
reviving the iproute2 side should be as easy as git revert this patch.

For more details see http://bugs.debian.org/149897

Regards, 
Andreas Henriksson


diff --git a/debian/rules b/debian/rules
index 132455f..4d825ca 100755
diff --git a/doc/ip-cref.tex b/doc/ip-cref.tex
index bb4eb78..b333842 100644
--- a/doc/ip-cref.tex
+++ b/doc/ip-cref.tex
@@ -1380,13 +1380,6 @@ database.
 even if it does not match any interface prefix. One application of this
 option may be found in~\cite{IP-TUNNELS}.
 
-\item \verb|equalize|
-
---- allow packet by packet randomization on multipath routes.
-Without this modifier, the route will be frozen to one selected
-nexthop, so that load splitting will only occur on per-flow base.
-\verb|equalize| only works if the kernel is patched.
-
 
 \end{itemize}
 
diff --git a/ip/iproute.c b/ip/iproute.c
index 6a2ea05..529159b 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -67,9 +67,9 @@ static void usage(void)
 	fprintf(stderr, "NODE_SPEC := [ TYPE ] PREFIX [ tos TOS ]\n");
 	fprintf(stderr, "             [ table TABLE_ID ] [ proto RTPROTO ]\n");
 	fprintf(stderr, "             [ scope SCOPE ] [ metric METRIC ]\n");
-	fprintf(stderr, "INFO_SPEC := NH OPTIONS FLAGS [ nexthop NH ]...\n");
+	fprintf(stderr, "INFO_SPEC := NH OPTIONS [ nexthop NH ]...\n");
 	fprintf(stderr, "NH := [ via ADDRESS ] [ dev STRING ] [ weight NUMBER ] NHFLAGS\n");
-	fprintf(stderr, "OPTIONS := FLAGS [ mtu NUMBER ] [ advmss NUMBER ]\n");
+	fprintf(stderr, "OPTIONS := [ mtu NUMBER ] [ advmss NUMBER ...
[ message continues ]

On Sat, 14 Mar 2009 17:37:35 +0100

applied, i think this was part of the aborted effort at more complex
multipath support. If it ever returns, we can re-enable it.
--

[ message continues ]

Its actually a lot older than that, it used to be an external patch
in the 2.4 era for per-packet multipath routing. I don't think
anyone will miss it :)


--

[ message continues ]