SCIENTIFIC-LINUX-USERS Archives

December 2013

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
John Lauro <[log in to unmask]>
Reply To:
John Lauro <[log in to unmask]>
Date:
Sun, 1 Dec 2013 12:21:11 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (78 lines)
If the switches have spanning tree protocol (default for most enterprise grade switches), they probably disable the port for 30-60 seconds to make sure there is no loop, and so loading the network driver may unlink the port long enough for the switch to disable the port again for 30-60 seconds.  To test for this issue, have you system working, run a constant ping, unplug the network, wait 5 seconds, plug it in and see how long it takes to start working again.

To avoid this problem, I configure most of my switch ports for spanning-tree portfast.  Alternatively, it might take upto a minute for dhcp to start working...


----- Original Message -----
> From: "olli hauer" <[log in to unmask]>
> To: [log in to unmask]
> Cc: "~Stack~" <[log in to unmask]>
> Sent: Sunday, December 1, 2013 11:36:06 AM
> Subject: Re: No DHCP on boot with a fresh install
> 
> On 2013-11-30 20:24, ~Stack~ wrote:
> > On 11/30/2013 01:03 PM, Nico Kadel-Garcia wrote:
> >> You shouldn't have to install NetworkManager for servers. It is
> >> *NOT*
> >> your friend.
> > 
> > I agree. However, I have wasted too much time already on this
> > problem
> > (several hours last night and several again this morning) and
> > installing
> > NetworkManager is the easy way out at the moment. I need and would
> > rather focus my attention on the project and not chasing down a
> > DHCP
> > problem. It really sucks I have to install so many more unneeded
> > packages just to get DHCP to work on boot. Such an absurd problem
> > to have.
> > 
> >> Neither is DHCP for servers, since sometimes upstream
> >> switches have not yet detected the active device by the time your
> >> client has scurried its way through the local host restart. In
> >> general, I keep servers set statically, and only set them to DHCP
> >> when
> >> planning a migration. You might this and see if it brings up the
> >> network at boot time reliably.
> > 
> > Agreed. Most of my servers are actually hard set. However, in this
> > particular project things would be so much better if I had a
> > working
> > DHCP at boot.
> > 
> >> If the upstream detection is the issue, put a "sleep 10" in the
> >> "start" stanza of /etc/nit.d/network. Amusingly enough, you can
> >> even
> >> put it in /etc/sysconfig/network-scripts/ifcfg-eth0, although that
> >> can
> >> get irritating and tools like system-config-network or
> >> NetworkManager
> >> will happily overwrite it.
> > 
> > Not a bad idea. I just tried it and didn't get it to work. Maybe 10
> > seconds is too short?
> > 
> > I will probably just script something when I have time and shove it
> > into
> > puppet. However, it seems to me that others are also having/seen
> > this
> > problem. Maybe this should be something fixed upstream?
> > 
> > Thanks for the help everyone!
> > ~Stack~
> 
> Are this bare metal boxes or virtual systems?
> 
> Perhaps you can find a hint with `dmesg' or by disabling the
> (annoying)
> splash boot so you see what happens when the network is initialized.
> 
> As workaround you can create a simple init script that tries to
> detect if the network is up and running (ping GW address) and
> executes
> ifdown/ifup.
> 
> --
> olli
> 

ATOM RSS1 RSS2