From owner-cvs-src@FreeBSD.ORG Tue Apr 15 04:38:28 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 6D245106566C for ; Tue, 15 Apr 2008 04:38:28 +0000 (UTC) (envelope-from qingli@speakeasy.net) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by mx1.freebsd.org (Postfix) with ESMTP id 44C998FC27 for ; Tue, 15 Apr 2008 04:38:27 +0000 (UTC) (envelope-from qingli@speakeasy.net) Received: (qmail 10838 invoked from network); 15 Apr 2008 04:11:47 -0000 Received: from dsl081-051-177.sfo1.dsl.speakeasy.net (HELO SAINTS) (qingli@[64.81.51.177]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 Apr 2008 04:11:46 -0000 From: "Qing Li" To: "'Andre Oppermann'" , "'Qing Li'" References: <200804130545.m3D5jEtd081771@repoman.freebsd.org> <4803D7E2.80000@freebsd.org> Date: Mon, 14 Apr 2008 21:11:50 -0700 Message-ID: <000201c89eae$d4dcfe10$b1335140@SAINTS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcieiIJefHcETRL+TlyGFFXgtN+cMgAJD+0g In-Reply-To: <4803D7E2.80000@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 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: Tue, 15 Apr 2008 04:38:28 -0000 Hi Andre, > > 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? > This is hash-based next-hop balancing. > > > > 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. > I think that is possible. Were you thinking more along the line of accidental route insertion ... Because users who are not familiar with ecmp probably won't ever bother with more than one route per destination. > > > > "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. > We should fix the above error message in general. > > Not being aware of the multipath functionality I would pull > out my last hair try to get rid of a route. > I think updating the manpage would be a necessary next step. > > How does this behave with common routing daemons; > Quagga/Zebra, OpenBGPD, OpenOSPFD? > Hmm... Good question, I haven't tried them but I will. Is this something you could help me with ? > > Do they have to be aware > of the multipath functionality? Will it confuse them? > I don't believe these routing protocols necessarily have to know about the multipath functionality. The routing protocols should continue to function wrt route insertion/deletion. You do bring up a good question about whether we should associate ownership with a route entry if multiple routing protocols are running in parallel. Is this a common practice from your experience ? And should we allow multiple routes with the same next-hop but different owners in the FIB ?? > > What about the other big missing piece; new-arp? ;-) > That's on its way. Julian is helping me testing the patch and reviewing the code etc. I am still debugging a locking/reference count issue and I hope to make good progress in the coming week. Soon ;-) > > Something for BSDCan? > Not for this May event ... -- Qing