From owner-cvs-src@FreeBSD.ORG Mon Apr 14 22:43:47 2008 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60CC91065672 for ; Mon, 14 Apr 2008 22:43:47 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id C66148FC2F for ; Mon, 14 Apr 2008 22:43:46 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 10988 invoked from network); 14 Apr 2008 21:23:07 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Apr 2008 21:23:07 -0000 Message-ID: <4803D7E2.80000@freebsd.org> Date: Tue, 15 Apr 2008 00:17:06 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Qing Li References: <200804130545.m3D5jEtd081771@repoman.freebsd.org> In-Reply-To: <200804130545.m3D5jEtd081771@repoman.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2008 22:43:47 -0000 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