From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 00:24:40 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58241106564A for ; Thu, 13 Sep 2012 00:24:40 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3408FC17 for ; Thu, 13 Sep 2012 00:24:39 +0000 (UTC) Received: from alph.allbsd.org (p3048-ipbf1204funabasi.chiba.ocn.ne.jp [123.218.144.48]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id q8D0OMkR001748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2012 09:24:32 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id q8D0OK9W052317; Thu, 13 Sep 2012 09:24:21 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 13 Sep 2012 09:21:32 +0900 (JST) Message-Id: <20120913.092132.1572055980229833778.hrs@allbsd.org> To: yanegomi@gmail.com From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Sep_13_09_21_32_2012_633)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Thu, 13 Sep 2012 09:24:32 +0900 (JST) X-Spam-Status: No, score=-96.3 required=13.0 tests=CONTENT_TYPE_PRESENT, FAKEDWORD_BACKQUOTE,ONLY1HOPDIRECT,RCVD_IN_RP_RNBL,SAMEHELOBY2HOP, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: Restarting interfaces and routing table stickiness X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 00:24:40 -0000 ----Security_Multipart(Thu_Sep_13_09_21_32_2012_633)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Garrett Cooper wrote in : ya> Hi -net! ya> I've been doing some IPv6 testing lately, and one of the issues ya> that I've run into in the past (since at least 7.0-CURRENT) is that if ya> I do `service netif restart `, e.g. `service netif restart` ya> multiple times, and have addresses statically configured in rc.conf, ya> more often than not the routing table doesn't properly get flushed and ya> my addresses become unreachable (even after I call `service routing ya> restart`). Recently, I ran into an issue with 9.1-RC1 where had to ya> kill ntpd before it would allow me to reach one of the addresses I had ya> assigned on a test server (server has a total of 4 physical NICs and 1 ya> vlan'ed interface). The only surefire method to get things back to a ya> sane state is to reboot the box (of course, please keep in mind that ya> I'm using the netif rc script and not using other commands like route ya> flush, route delete, etc). ya> This behavior can be simply triggered like so on 8.x and below like so: ya> ya> /etc/rc.d/network_ipv6 restart ya> /etc/rc.d/network_ipv6 restart Do you have a procedure which can reproduce the problem on 9.x and/or output with rc_debug="YES"? I guess the cause was that initialization of the routing table and interface configuration are separated, and it ended up being some incomplete configuration when restarting. -- Hiroki ----Security_Multipart(Thu_Sep_13_09_21_32_2012_633)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlBRJwwACgkQTyzT2CeTzy0CTgCg2sndjXOqtGE+sgqEyt8DVTk2 GsYAoMLQh4kcFx52IgFHw1b+IaYwqhFu =qG1m -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Sep_13_09_21_32_2012_633)----