From owner-freebsd-questions@FreeBSD.ORG Mon Apr 25 22:05:38 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3170D1065674 for ; Mon, 25 Apr 2011 22:05:38 +0000 (UTC) (envelope-from fourquau@phare.normalesup.org) Received: from nef2.ens.fr (nef2.ens.fr [129.199.96.40]) by mx1.freebsd.org (Postfix) with ESMTP id B78A98FC16 for ; Mon, 25 Apr 2011 22:05:37 +0000 (UTC) Received: from phare.normalesup.org (phare.normalesup.org [129.199.129.80]) by nef2.ens.fr (8.13.6/1.01.28121999) with ESMTP id p3PM5Zb8037981 ; Tue, 26 Apr 2011 00:05:35 +0200 (CEST) X-Envelope-To: freebsd-questions@freebsd.org Received: by phare.normalesup.org (Postfix, from userid 1003) id 88A96BC24C; Tue, 26 Apr 2011 00:05:35 +0200 (CEST) Date: Tue, 26 Apr 2011 00:05:35 +0200 From: Lionel Fourquaux To: Daniel Marsh Message-ID: <20110425220535.GA9237@phare.normalesup.org> References: <20110424202954.GA16373@phare.normalesup.org> <201104242343.p3ONhBld001779@mail.r-bonomi.com> <20110425115313.GB4647@phare.normalesup.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: 24B5 DFFD 45C1 E9E4 8A16 B30B AB33 3E73 C79D F8E1 User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.1.4 (nef2.ens.fr [129.199.96.32]); Tue, 26 Apr 2011 00:05:35 +0200 (CEST) Cc: freebsd-questions@freebsd.org Subject: Re: routing to a directly attached subnet without an address in this subnet X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 22:05:38 -0000 On Mon, Apr 25, 2011 at 10:17:40PM +1000, Daniel Marsh wrote: >What you need to verify is the default routes on the client hosts. It's very >likely your packets and your initial route add commands on your dual host >machine are correct, yet the return route on the other clients are >incorrect. I have checked that. Actually, I can ping the router from the clients. What does not work is initiating a packet exchange from the router's side. Short reminder: em0 has addresses fe80::1234:56ff:fe78:9abc and 2001:db8::1 em1 has address fe80::1234:56ff:fe78:9abd default route is to em0 2001:db8:0:1::/64 is router to em1 (route add -inet6 2001:db8:0:1::/64 -iface em1) clients connected to em1 have addresses in 2001:db8:0:1::/64 and default route to fe80::1234:56ff:fe78:9abd If I reboot the router, then try to ping a client in 2001:db8:0:1::/64, directly connected to em1, ping6 fails with "sendmsg: Operation not permitted". tcpdump does not show anything being sent to this client. The client's MAC does not show up in "ndp -a". If I ping the router from the client, I get answers. The client's MAC show up in the NDP table, and I can ping the client from the router as long as it is still listed in the NDP table. If I clear the table with "ndp -c", I can't ping from the router any more. If I reboot and add a static entry for the client in the NDP table, I can ping this client. All this seems to point to NDP as the root of the problem: it looks like it is not aware of the addition of 2001:db8:0:1::/64 to the routing table. I do not see any way to give the missing information to NDP other than adding an address to em1. (Adding static entries for all the clients would not be manageable in the long run). Google seems to turn up some mentions of "cloning routes" that look like a way to solve this (I'm not quite sure), but this was apparently removed in a recent reimplementation of ARP+NDP (arp-v2). Maybe some functionality was lost in the process, but I don't know about this.