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
From: kickstart-list-bounces@xxxxxxxxxx [mailto:kickstart-list-bounces@xxxxxxxxxx] On Behalf Of SSTinsley@xxxxxxxxxxxxxx
Sent: Thursday, May 17, 2007 9:12 AM
To: Discussion list about Kickstart
Subject: RE: Unable to get any httprequests: Unable toretreive netstg2.imgfile
kickstart-list-bounces@xxxxxxxxxx wrote on 05/17/2007 08:46:19 AM:
> On Thu, 2007-05-17 at 07:20 -0400, SSTinsley@xxxxxxxxxxxxxx wrote:
> > kickstart-list-bounces@xxxxxxxxxx wrote on 05/16/2007 08:28:48 PM:
> > > The reason you can get an IP and PXEboot is because the NIC is up
> > for
> > > more than 30 seconds, which gives the switch time to negotiate with
> > the
> > > NIC and turn up the port. When anaconda starts, it recycles the NIC
> > (to
> > > load the driver). If you have portfast issues, anaconda will
> > timeout
> > > before your switch makes the port live.
> > >
> > > Ananacoda will also recycle the NIC one more time after it gets the
> > > ks.cfg, but that one never causes portfast timeout issues.
> > >
> >
> > I here what your saying. I took your suggestion to the network guys
> > and they confirmed the
> > switch is configured correctly. So short of calling them liars, I am
> > pretty much at a
> > standstill and have to go with the ks.cfg on CDROM.
>
> you may want to add "nicdelay=40 linksleep=30" to you kernel command
> line.
>
> I didn't see that in any of your posts so I thought I'd mention it.
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189795
>
> Note: you can add these to your ifcfg-eth0 conf file as well
> # No portfast, wait 30s
> LINKDELAY=30
> # DISABLE stupid ZeroConf address
> NOZEROCONF=1
>
>
> I've been on this list for a long time and been quite mostly but this is
> a long thread and I thought I would hop in share my thoughts with the
> rest of the Internet as well :)
>
> I'm not calling your networking team a liar, but in the same effect, you
> appear to be experiencing an issue where linkdelay and nicdelay my come
> in handy for you (works for both static and dhcp)
>
> --
> - Kevin Landreth - RHCE
> - Sr. Systems Architect
While this may solve the problem (and I will try it if I have time), I think
the thread shows that there is an issue. The fact that DHCP works fine during
the PXE boot and download of the kernel and fails in Anaconda should be
reason enough to a fix to be made. Make the DHCP operate consistently during the
whole process.
Thanks for your help
NOTE: THIS DOCUMENT MAY CONTAIN CONFIDENTIAL AND NONPUBLIC INFORMATION. IT
IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL(S) OR ENTITY(IES) NAMED ABOVE,
AND OTHERS SPECIFICALLY AUTHORIZED TO RECEIVE IT. If you are not the intended
recipient of this document, you are notified that any review, dissemination,
distribution or copying of this communication is prohibited. If you have
received this communication in error, please notify me immediately by return
email, delete the electronic message and destroy any printed copies. Thank you
for your cooperation.
