Re: Broadcom, DHCP

[Brian Long <brilong cisco com>]

Ed Brown wrote:

> On Mon, 2005-07-25 at 11:44, Howard Johnson wrote:
>  
>
> > On Mon, 2005-07-25 at 18:47 +0200, Bjorn S. Nilsson wrote:
> >    
>
>  
>
> > > Laptops and desktops with Broadcom NetXtreme gigabit controllers 
> > > often fail to get an IP-address using DHCP, but only in the instal-
> > > lation phase. I.e., if I wait until the DHCP query has timed out
> > > and enter a fixed address the card works. Later, after installation
> > > and reboot DHCP works flawlessly. So, there seems to be something
> > > specific to the installer causing this problem. Any hints?
> > >      
>
>  
>
> > Are you using Cisco switches? I find that pump/anaconda doesn't have a
> > long enough timeout to deal with spanning tree blocking the port for the
> > first 45 seconds or so. I get around this problem with by either
> > plugging something dumb between the machine and the switch, or turning
> > on portfast. Every time anaconda runs pump, the NIC drops and raises the
> > link, which triggers spanning tree to block the port while it checks for
> > loops in the network.
> >    
>
> This is an old issue, been around a couple of years at least (see
> anaconda and kickstart archives too), and a real PITA.  It's not
> restricted to switch manufacturer, it's not restricted to gigabit
> NIC/driver, it's not tied to the network 'bootproto' or the install type
> (ftp/http/NFS).  The only common thread is anaconda.  I'd love to
> understand why it hasn't been fixed, or handled, in anaconda.
>
> Non-cisco switches might not have 'portfast'.  We've disabled
> spanning-tree, or use an intermediate 10/100 hub or switch to work
> around this.  
>  
It would be nice if you guys escalated this within your Red Hat support 
org.  So far we've been told if would be considered for RHEL 5  :-(

We asked for a simple flag to throw anaconda asking it to retry for up 
to 45 seconds before giving up.  Even this was rejected.

The bugzilla is 151908 and our issue tracker is 69391 if you want to 
open a similar issue tracker with your support ID.  This is a snippet 
from our TAM:
----------------
From my discussions with Engineering the thoughts are that adding a 
default sleep statement would be bad for others who dont have this 
issue, and that adding a command line arguement would go against what 
they are typically used for.  They should be used in cases to control 
getting to the kickstart, but not triggering changes to the behaviour of 
the code.

Presently we are looking into RHEL5 for making some changes, many have 
reported that pxelinux does solve this issue, although we have not seen 
these results in house.
----------------

/Brian/