<div dir="ltr">Hi John,<div><br></div><div>Can you take a look at <a href="https://bugs.launchpad.net/neutron/+bug/1190613">https://bugs.launchpad.net/neutron/+bug/1190613</a> ?</div><div>Looks like the exact issue you're talking about and it was fixed just recently.</div>
<div><br></div><div>Thanks,</div><div>Eugene.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 27, 2013 at 10:22 PM, John Gruber <span dir="ltr"><<a href="mailto:john.t.gruber@gmail.com" target="_blank">john.t.gruber@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br>So I got it work, but I need guidance from the OVS iptables gang on what the reasoning was and how I fix it in a 'compliant' manner. <br>
<br></div>Q. Why are the iptables rules on the OVS output chains for the interfaces written as if the vif should only have ONE IP address assign where quantum can assign multiple fixedips? <br>
<div><br></div><div>For the example where IP address 10.0.60.20 was assigned to my guest VM on an external interface and assign at boot, and then I added 10.0.60.22 via nova --add-fixed-ip vm-uuid net-uuid...<br></div><div>
<br>Here is what I had in my iptables rules after adding the second fixedip:<br><br><span style="font-family:courier new,monospace">iptables -L quantum-openvswi-o8a508818-0 --line-numbers<br>Chain quantum-openvswi-o8a508818-0 (2 references)<br>
num target prot opt source destination <br>1 DROP all -- anywhere anywhere MAC ! FA:16:3E:41:6B:15<br>2 RETURN udp -- anywhere anywhere udp spt:bootpc dpt:bootps<br>
<b>3 DROP all -- !10.0.62.20 anywhere <br>4 DROP all -- !10.0.62.22 anywhere <br></b>5 DROP udp -- anywhere anywhere udp spt:bootps dpt:bootpc<br>
6 DROP all -- anywhere anywhere state INVALID<br>7 RETURN all -- anywhere anywhere state RELATED,ESTABLISHED<br>8 RETURN all -- anywhere anywhere <br>
9 quantum-openvswi-sg-fallback all -- anywhere anywhere <br> <br></span></div><div><span style="font-family:courier new,monospace"><br></span></div><div>This obviously will not work. The rules shadow each other and cut off all outbound access from the guest VM on that network. Which is exactly what I was observing..<br>
<br></div><div>Running: iptables -D quantum-openvswi-o8a508818-0 4<br><br></div><div>And my access to 10.0.62.20 came back... <br></div><div><br>Running iptables -D quantum-openvswi-o8a508818-0 3<br></div><div class="gmail_extra">
<br></div><div class="gmail_extra">And my access to 10.0.62.22 started working...<br><br><br></div><div class="gmail_extra">Please tell me we did not intend to create a cloud where quantum has no problems assigning multiple fixed IPs to a port, but iptables will eat them all up! <g> Oh the humanity... <br>
<br></div><div class="gmail_extra">I know how to make it work and can hunt down the iptables root wrapper command, but what should we do for this? I could not find an existing bug.. <br></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">
<br>
</div><div class="gmail_extra">John<br></div></font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>
<br></blockquote></div><br></div>