<html><head></head><body><div class="ydpe4526691yahoo-style-wrap" style="font-family:times new roman, new york, times, serif;font-size:16px;"><div></div>
<div dir="ltr" data-setdir="false">Thanks Julia. </div><div dir="ltr" data-setdir="false">Yes, portfast is enabled on the ports of the TOR switch.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false"><div dir="ltr" data-setdir="false">Regards,</div><div dir="ltr" data-setdir="false">Fred.</div><div><br></div></div><div dir="ltr" data-setdir="false"><br></div>
</div><div id="ydpc4c8db2byahoo_quoted_1272198589" class="ydpc4c8db2byahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Tuesday, October 8, 2019, 10:09:35 AM PDT, Julia Kreger <juliaashleykreger@gmail.com> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">One other thing that comes to mind at 30 seconds is spanning-tree port<br clear="none">forwarding delay. PXE boot often thinks once carrier is up, that it<br clear="none">can try and send/receive packets, however switches may still block<br clear="none">traffic waiting for spanning-tree packets. Just from a limiting<br clear="none">possible issues, it might be a good thing to double check network side<br clear="none">to make sure "portfast" is the operating mode for the physical ports<br clear="none">attached to that flat network. What this would look like is the<br clear="none">machine appears to DHCP, but the packets would never actually reach<br clear="none">the DHCP server.<br clear="none"><br clear="none">-Julia<br clear="none"><div class="ydpc4c8db2byqt5709047908" id="ydpc4c8db2byqtfd98636"><br clear="none">On Tue, Oct 8, 2019 at 9:55 AM <a shape="rect" href="mailto:fsbiz@yahoo.com" rel="nofollow" target="_blank">fsbiz@yahoo.com</a> <<a shape="rect" href="mailto:fsbiz@yahoo.com" rel="nofollow" target="_blank">fsbiz@yahoo.com</a>> wrote:<br clear="none">><br clear="none">> Thanks Julia. We have set the port_setup_delay to 30.<br clear="none">><br clear="none">><br clear="none">> # Delay value to wait for Neutron agents to setup sufficient<br clear="none">> # DHCP configuration for port. (integer value)<br clear="none">> # Minimum value: 0<br clear="none">> port_setup_delay = 30<br clear="none">><br clear="none">> >We're hoping that in the U<br clear="none">> >cycle, we'll finally have things in place where neutron tells ironic<br clear="none">> >that the port setup is done and that the machine can be powered-on,<br clear="none">> >but not all the code made it during Train.<br clear="none">><br clear="none">> This would be perfect.<br clear="none">><br clear="none">> Fred.<br clear="none">><br clear="none">><br clear="none">><br clear="none">><br clear="none">> On Tuesday, October 8, 2019, 09:32:44 AM PDT, Julia Kreger <<a shape="rect" href="mailto:juliaashleykreger@gmail.com" rel="nofollow" target="_blank">juliaashleykreger@gmail.com</a>> wrote:<br clear="none">><br clear="none">><br clear="none">> While not necessarily direct scaling of that subnet, you may want to<br clear="none">> look at ironic.conf's [neutron]port_setup_delay option. The default<br clear="none">> value is zero seconds, but increasing that value will cause the<br clear="none">> process to pause a little longer to give time for the neutron agent<br clear="none">> configuration to update, as the agent may not even know about the<br clear="none">> configuration as there are multiple steps with-in neutron, by the time<br clear="none">> the baremetal machine tries to PXE boot. We're hoping that in the U<br clear="none">> cycle, we'll finally have things in place where neutron tells ironic<br clear="none">> that the port setup is done and that the machine can be powered-on,<br clear="none">> but not all the code made it during Train.<br clear="none">><br clear="none">> -Julia<br clear="none">><br clear="none">> On Tue, Oct 8, 2019 at 9:15 AM <a shape="rect" href="mailto:fsbiz@yahoo.com" rel="nofollow" target="_blank">fsbiz@yahoo.com</a> <<a shape="rect" href="mailto:fsbiz@yahoo.com" rel="nofollow" target="_blank">fsbiz@yahoo.com</a>> wrote:<br clear="none">> ><br clear="none">> > Hi folks,<br clear="none">> ><br clear="none">> > We have a rather large flat network consisting of over 300 ironic baremetal nodes<br clear="none">> > and are constantly having the baremetals timing out during their PXE boot due to<br clear="none">> > the dhcp agent not able to respond in time.<br clear="none">> ><br clear="none">> > Looking for inputs on successful DHCP scaling techniques that would help mitigate this.<br clear="none">> ><br clear="none">> > thanks,<br clear="none">> > Fred.<br clear="none">><br clear="none"><br clear="none"></div></div></div>
</div>
</div></body></html>