Date: Mon, 24 Oct 2011 18:03:27 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: ntpd couldn't resolve host name on system boot Message-ID: <20111025010327.GA75437@icarus.home.lan> In-Reply-To: <B26B1B7BC38B4479B103B78B2175234D@multiplay.co.uk> References: <4EA5EBB5.3090101@quip.cz> <20111024232750.GA74032@icarus.home.lan> <B26B1B7BC38B4479B103B78B2175234D@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 25, 2011 at 12:36:56AM +0100, Steven Hartland wrote: > ----- Original Message ----- From: "Jeremy Chadwick" > <freebsd@jdc.parodius.com> > > >The problem is that the networking layer is not TRULY available by the > >time ntpd starts. This does have to do with NIC drivers, but the same > >behaviour can be seen on all NICs, including excellent ones like em(4). > > This is generally caused by links to high end switches e.g. cisco which > havent had their "server" ports configured with portfast or similar > settings. This creates quite a delay once link establishes before traffic > is passed and hence the issue. Correct. Folks using STP, RSTP, or LLDP are most likely to see this. However, in our environment we have all of these turned off on our ProCurve switches yet we still see a ~1 second period of time between when the kernel says "em0 is up" vs. when actual packets flow. My point is that even in bare-bones environments (consumer switches, etc.) it's likely that there will be a small period of time where layer 3 packets aren't actually working yet, despite layer 1 and (a portion of) layer 2 being done. > netwait is an excellent script which fixes this and other network dependency > issues, something we use as standard on all our machines now :) It's a hackish workaround for something that should be solved elsewhere, but solving it elsewhere has already been discussed at length in the past so I won't get into it here. (Simple version: we really need something like "svcs" for Solaris, or one of those service-wrapper daemons that Linux and other OSes use. But let's not discuss that here please) netwait's "design model" is very specific given people's needs; the original design worked fine on some machines (all of ours) but I started getting reports of problems from people using vlan(4) and bge(4), etc... so the way it works now is actually reliable for all current NICs and "weirder" environments. The one shortcoming of netwait is that it doesn't support waiting for multiple NICs. Some people have dual-homed environments where they really would like to wait for both, say, em0 and em1, to come up and be functional before any more scripts are started. I left that as a project for someone else, but it's something that should be added given its importance. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111025010327.GA75437>