Brians on the right track with regard to port-fast. What you want to enable there is on a per port basis. It's not a general spanning tree config. I mention this because your earlier mail only showed some general spanning tree settings. I have seen what you describe. It will work for the pxe dhcp request but fail on the kickstart dhcp request. It depends on how fast your machine boots and if the interface gets reset right before pxe dhcp. Spanning tree can take up to 50 seconds to go through the cycle of blocking, listening, learning, before it starts forwarding on that port again. Your looking at at least 30 seconds. Kickstart then resets the interface, which make the interface leave the bridge, and thus when it reconnects the switch port goes back to blocking mode and goes through the cycle again. Here what you'd change: cat5k> (enable) show port spantree 2/3 Port(s) Vlan Port-State Cost Priority Portfast Channel_id ------------------------ ---- ------------- ----- -------- ---------- ---------- 2/3 1 forwarding 19 32 disabled 0 cat5k> (enable) set spantree portfast 2/3 enable Warning: Spantree port fast start should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc. to a fast start port can cause temporary spanning tree loops. Use with caution. Spantree port 2/3 fast start enabled. cat5k> (enable) show port spantree 2/3 Port(s) Vlan Port-State Cost Priority Portfast Channel_id ------------------------ ---- ------------- ----- -------- ---------- ---------- 2/3 1 forwarding 19 32 enabled 0 cat5k> (enable) Enabling Port fast on all ports that are only going to be connected to hosts is a good practice. One example of why you would want do do this is NTP would have problems setting it's initial time on boot up since on a fast machine NTP may start before the switch port is in forwarding mode. Also notice the warning it gave. So you don't want to plug in a switch to that port or it could cause problems. To protect against that versions of CatOS 5.4.1 have a feature called BPDU Guard. If you enable this then the port will get disabled if it detects the device being connected is running spanning tree. You can control how long it will disable for as well. cat5k> (enable) set spantree portfast bpdu-guard enable Spantree portfast bpdu-guard enabled on this switch. cat5k> (enable) See http://www.cisco.com/warp/public/473/65.html for more information. Thanks Scott On Mon, 2004-06-07 at 14:52, Andy Ciordia wrote: > Tom Diehl wrote: > > >Is this your problem: > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114092 > > > >Tom > > > > > > > No sir, not quite. The bail point is the same but the error is different. > > <pastes from the beginning> > Ethernet Card: > eth0: Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] > (PCIX:133MHz:64-bit) 10/100/1000BaseT > > Problem: Installing from PXE, fails to aquire DHCP address as Kickstart > begins. > > Summary: > 1. PXE-Booting aquires DHCP w/ MAC matching > 2. Kernel is passed over and Boots > 3. Kickstart engages and knows to boot over HTTP, its first job is to > aquire its address through DHCP. The first broadcast is never handled > and times out, thus causing a stop point for the user asking methodology > for aquiring an address. > 4. When you select OK to try DHCP again, it aquires, and the > installation continues as it should. > > I've seen this problem reported before, but never really seen an > applicable solution. In the DHCP logs I see a broadcast coming over the > lines but I don't know why its not getting a response at this time and > why it gets it on the second trial. The Console logs: > > Sending DHCP request through device eth0 > Waiting for link > 5 seconds . . . > Pump told us: no DHCP reply recieved. > </paste> > > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/kickstart-list
