<div dir="ltr">><span style="font-size:12.8000001907349px">How is Neutron breaking this?  If I move a port on my physical switch to a</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">different subnet, can you still communicate with the host sitting on it?</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Probably not since it has a view of the world (next-hop router) that no longer</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">exists, and the network won't route packets for it's old IP address to the new</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">location.  It has to wait for it's current DHCP lease to tick down to the point</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">where it will use broadcast to get a new one, after which point it will work.</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">That's not just moving to a different subnet. That's moving to a different broadcast domain. Neutron supports multiple subnets per network (broadcast domain). An address on either subnet will work. The router has two interfaces into the network, one on each subnet.[2]</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">></span><span style="font-size:12.8000001907349px">Does it work on Windows VMs too?  People run those in clouds too.  The point is</span></div><span style="font-size:12.8000001907349px">that if we don't know if all the DHCP clients will support it then it's a</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">non-starter since there's no way to tell from the server side.</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">It appears they do.[1] Even for clients that don't, the worst case scenario is just that they are stuck where we are now.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">></span><span style="font-size:12.8000001907349px">"... then the deployer can adjust the value upwards...", hmm, can they adjust it</span></div><span style="font-size:12.8000001907349px">downwards as well?  :)</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Yes, but most people doing initial openstack deployments don't and wouldn't think to without understanding the intricacies of the security groups filtering in Neutron.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div>><span style="font-size:12.8000001907349px">I'm glad you're willing to "boil the ocean" to try and get the default changed,</span></div><span style="font-size:12.8000001907349px">but is all this really worth it when all you have to do is edit the config file</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">in your deployment?  That's why the value is there in the first place.</span><div><div><span style="font-size:12.8000001907349px"><br></span></div><div>The default value is basically incompatible with port IP changes. We shouldn't be shipping defaults that lead to half-broken functionality. What I'm understanding is that the current default value is to workaround shortcomings in dnsmasq. This is an example of implementation details leaking out and leading to bad UX. </div><div><br></div><div>If we had an option to configure how often iptables rules were refreshed to match their security group, there is no way we would have a default of 12 hours. This is essentially the same level of connectivity interruption, it just happens to be a narrow use case so it hasn't been getting any attention.</div><div><br></div><div>To flip your question around, why do you care if the default is lower? You already adjust it beyond the 1 day default in your deployment, so how would a different default impact you?</div><div><br></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">1. <a href="http://support.microsoft.com/kb/121005">http://support.microsoft.com/kb/121005</a></span></div></div><div><span style="font-size:12.8000001907349px">2. Similar to using the "secondary" keyword on Cisco devices. Or just the "ip addr add" command on linux.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 1:34 PM, Brian Haley <span dir="ltr"><<a href="mailto:brian.haley@hp.com" target="_blank">brian.haley@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/29/2015 03:55 AM, Kevin Benton wrote:<br>
>>Why would users want to change an active port's IP address anyway?<br>
><br>
> Re-addressing. It's not common, but the entire reason I brought this up is<br>
> because a user was moving an instance to another subnet on the same network and<br>
> stranded one of their VMs.<br>
><br>
>> I worry about setting a default config value to handle a very unusual use case.<br>
><br>
> Changing a static lease is something that works on normal networks so I don't<br>
> think we should break it in Neutron without a really good reason.<br>
<br>
</span>How is Neutron breaking this?  If I move a port on my physical switch to a<br>
different subnet, can you still communicate with the host sitting on it?<br>
Probably not since it has a view of the world (next-hop router) that no longer<br>
exists, and the network won't route packets for it's old IP address to the new<br>
location.  It has to wait for it's current DHCP lease to tick down to the point<br>
where it will use broadcast to get a new one, after which point it will work.<br>
<span class=""><br>
> Right now, the big reason to keep a high lease time that I agree with is that it<br>
> buys operators lots of dnsmasq downtime without affecting running clients. To<br>
> get the best of both worlds we can set DHCP option 58 (a.k.a dhcp-renewal-time<br>
> or T1) to 240 seconds. Then the lease time can be left to be something large<br>
> like 10 days to allow for tons of DHCP server downtime without affecting running<br>
> clients.<br>
><br>
> There are two issues with this approach. First, some simple dhcp clients don't<br>
> honor that dhcp option (e.g. the one with Cirros), but it works with dhclient so<br>
> it should work on CentOS, Fedora, etc (I verified it works on Ubuntu). This<br>
> isn't a big deal because the worst case is what we have already (half of the<br>
> lease time). The second issue is that dnsmasq hardcodes that option, so a patch<br>
> would be required to allow it to be specified in the options file. I am happy to<br>
> submit the patch required there so that isn't a big deal either.<br>
<br>
</span>Does it work on Windows VMs too?  People run those in clouds too.  The point is<br>
that if we don't know if all the DHCP clients will support it then it's a<br>
non-starter since there's no way to tell from the server side.<br>
<span class=""><br>
> If we implement that fix, the remaining issue is Brian's other comment about too<br>
> much DHCP traffic. I've been doing some packet captures and the standard<br>
> request/reply for a renewal is 2 unicast packets totaling about 725 bytes.<br>
> Assuming 10,000 VMs renewing every 240 seconds, there will be an average of 242<br>
> kbps background traffic across the entire network. Even at a density of 50 VMs,<br>
> that's only 1.2 kbps per compute node. If that's still too much, then the<br>
> deployer can adjust the value upwards, but that's hardly a reason to have a high<br>
> default.<br>
<br>
</span>"... then the deployer can adjust the value upwards...", hmm, can they adjust it<br>
downwards as well?  :)<br>
<span class=""><br>
> That just leaves the logging problem. Since we require a change to dnsmasq<br>
> anyway, perhaps we could also request an option to suppress logs from renewals?<br>
> If that's not adequate, I think 2 log entries per vm every 240 seconds is really<br>
> only a concern for operators with large clouds and they should have the<br>
> knowledge required to change a config file anyway. ;-)<br>
<br>
</span>I'm glad you're willing to "boil the ocean" to try and get the default changed,<br>
but is all this really worth it when all you have to do is edit the config file<br>
in your deployment?  That's why the value is there in the first place.<br>
<br>
Sorry, I'm still unconvinced we need to do anything more than document this.<br>
<div class="HOEnZb"><div class="h5"><br>
-Brian<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>