Unable to get any httprequests: Unable toretreive netstg2.imgfile
Ed Brown
ebrown at lanl.gov
Thu May 17 18:39:13 UTC 2007
Thanks for bringing the historical perspective to this question, it
has indeed been kicked around for years now. But I disagree with the
assertion that it's only a Cisco problem. I remember at least two
other switch manufacturers involved, including my direct experience
with 3com gigabit switches. Also, it hasn't only caused problems for
pxe/dhcp installs, but also static ip installs using http and ftp.
The only common factors seem to have been gigabit switches/nics, STP,
and anaconda.
Wherever the root causes lay, it's a problem during redhat
installations, and no other circumstances, that I know about anyway.
If it CAN be fixed or worked around in anaconda, then it should be, if
only for the sake of RedHat's reputation and their customers'
experience. While I don't understand all the issues involved, I do
appreciate the recent options intended to help in these situations,
and hope your additional suggestions are acted on too.
-Ed
Shabazian, Chip wrote:
>
> While I completely agree that this is something that has been a hassle
> and has been the source of more problems than anything I've seen related
> to kickstarting systems, we need to keep in mind that these workarounds
> are being put into place to deal with a "feature" of the switch.
> Wouldn't it be better for Cisco to fix STP so that if it saw a DHCP
> packet, it would forward that packet while it determines if it's going
> to allow that port on the network? I can't imagine any loops being
> created by forwarding and responding to DHCP packets while ensuring
> there are no loops.
>
> We always see this problem on Cisco gear, and in the past 4+ years, I've
> only seen this issue as a possibility on one other type of switch (but
> the person never responded to the list on whether or not the known Cisco
> workarounds helped), yet people think this is an "anaconda" or
> "kickstart" problem, not a "Cisco" problem.
>
> Now, *I* sure would like to see the timeout for pump increased from 30
> seconds to 60 seconds, but that would probably piss off even MORE people
> since I'm sure there are a lot more people who get frustrated waiting 30
> seconds for pump to timeout during boot if their dhcp server is down, or
> if they have more than one interface and don't know how to turn off dhcp
> on the unused interfaces, etc.
>
> I guess the ideal solution would be an option for pump that does
> increase the timeout that could be passed from anaconda, or an option in
> anaconda such as dhcpretry=X where you could set the system to retry
> dhcp X number of times without recycling the NIC and starting the
> negotiation dance again.
>
> But at the end of the day, please keep in mind that these are all work
> arounds for the Cisco STP feature, that while valuable, is the actual
> root cause.
>
> Chip
More information about the Kickstart-list
mailing list