Date: Tue, 15 Apr 2008 00:17:06 +0200 From: Andre Oppermann <andre@freebsd.org> To: Qing Li <qingli@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf files options src/sys/net radix.c radix.h route.c route.h rtsock.c src/sys/netinet in_proto.c ip_output.c src/sys/netinet6 in6_proto.c in6_src.c nd6_nbr.c Message-ID: <4803D7E2.80000@freebsd.org> In-Reply-To: <200804130545.m3D5jEtd081771@repoman.freebsd.org> References: <200804130545.m3D5jEtd081771@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Qing Li wrote:
> qingli 2008-04-13 05:45:14 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/conf files options
> sys/net radix.c radix.h route.c route.h rtsock.c
> sys/netinet in_proto.c ip_output.c
> sys/netinet6 in6_proto.c in6_src.c nd6_nbr.c
> Log:
> This patch provides the back end support for equal-cost multi-path
> (ECMP) for both IPv4 and IPv6. Previously, multipath route insertion
Nice! Long overdue that we get this functionality. :-)
Do you do hash-based next-hop balancing ("flow"-aware) or packet
based round robin? Should it be made an option to switch between them
(globally) like on Cisco routers?
> is disallowed. For example,
>
> route add -net 192.103.54.0/24 10.9.44.1
> route add -net 192.103.54.0/24 10.9.44.2
>
> The second route insertion will trigger an error message of
> "add net 192.103.54.0/24: gateway 10.2.5.2: route already in table"
Would it make sense to retain this behavior by default (POLA) and have
multi-path being enabled via sysctl like packet forwarding in general?
Just adding the same route twice with different next-hops can lead to
very confusing situations for the users which are not used to multi-path.
> Multiple default routes can also be inserted. Here is the netstat
> output:
>
> default 10.2.5.1 UGS 0 3074 bge0 =>
> default 10.2.5.2 UGS 0 0 bge0
>
> When multipath routes exist, the "route delete" command requires
> a specific gateway to be specified or else an error message would
> be displayed. For example,
>
> route delete default
>
> would fail and trigger the following error message:
>
> "route: writing to routing socket: No such process"
> "delete net default: not in table"
Can this be made more descriptive? This messages are about as confusing
and non-descript as possible. Not being aware of the multipath functionality
I would pull out my last hair try to get rid of a route.
> On the other hand,
>
> route delete default 10.2.5.2
>
> would be successful: "delete net default: gateway 10.2.5.2"
>
> One does not have to specify a gateway if there is only a single
> route for a particular destination.
>
> I need to perform more testings on address aliases and multiple
> interfaces that have the same IP prefixes. This patch as it
> stands today is not yet ready for prime time. Therefore, the ECMP
> code fragments are fully guarded by the RADIX_MPATH macro.
> Include the "options RADIX_MPATH" in the kernel configuration
> to enable this feature.
How does this behave with common routing daemons; Quagga/Zebra, OpenBGPD,
OpenOSPFD? Do they have to be aware of the multipath functionality? Will
it confuse them?
What about the other big missing piece; new-arp? ;-) Something for BSDCan?
--
Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4803D7E2.80000>