<div dir="ltr">Thank you both for the information. <div><br></div><div style>I see that the compute node has some iptables rules for the instance -- one in particular that filters the instance's mac address -- but deleting this rule doesn't resolve the issue. So my guess is that it's the flow table that Salvatore mentioned which is ultimately controlling the filtering. </div>
<div style><br></div><div style>At the moment, I don't know enough about open vswitch to make custom changes to the flow table. For now, setting the bridge's mac address as the same mac of the virtual interface is a good work around.</div>
<div style><br></div><div style>Thanks again,</div><div style>Joe</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 30, 2013 at 5:57 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.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">I was not aware that security groups for OVS already enforced anti spoofing rules.<div>That's good to know.</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>Salvatore</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br>
<div class="gmail_quote">On 1 May 2013 00:55, Aaron Rosen <span dir="ltr"><<a href="mailto:arosen@nicira.com" target="_blank">arosen@nicira.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">Also, the security group stuff locks down the port to be the mac+ip of the quantum port mac+ip. If you create a new bridge and add ethX to it you'll also have to set the mac on your bridge to be the same as ethX (which is the mac that quantum handed out). <span><font color="#888888"><div>
<br>Aaron</div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 30, 2013 at 4:25 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.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">Hi Joe,<div><br></div><div>are you using the OVS plugin with GRE overlays?</div><div>In that case your problem might be the fact that the plugin pushes a OVS flow entry which applies the 'local' vlan tag only to packet directed to the VM's mac [1]</div>
<div><br></div><div>To me, this does not look like a bug; it's probably intended behaviour, as it kind of implements mac spoofing prevention. In the future we might also expect stricter anti-spoof checking; on the other side a change for administratively enabling promiscuos mode might be welcome - this should allow you to do nested OVS.</div>
<div><br></div><div>Salvatore</div><div><br></div><div>[1] <a href="https://github.com/openstack/quantum/blob/master/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py#L448" target="_blank">https://github.com/openstack/quantum/blob/master/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py#L448</a></div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On 30 April 2013 22:08, Joe Topjian <span dir="ltr"><<a href="mailto:joe.topjian@cybera.ca" target="_blank">joe.topjian@cybera.ca</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hello,<div><br></div><div>I have OpenStack (Grizzly) up and running with Quantum. I'm using the Open vSwitch plugin, per-tenant routing, and network namespaces. As far as I'm aware, this is all set up correctly as instances that I create are able to retrieve an IP address via DHCP, reach the metadata server, and reach the outside internet.</div>
<div><br></div><div>The issue that I'm running into is that when I install Open vSwitch on the instance itself, I'm unable to create working bridges. For example:</div><div><br></div><div>ovs-vsctl add-br br-eth0</div>
<div>ovs-vsctl add-port br-eth0 eth0</div><div>(swap IPs from eth0 to br-eth0, kill dhcp, etc etc)</div><div><br></div><div>Traffic isn't flowing properly, though.</div><div><br></div><div>
If I run a continuous ping and run tcpdump on both the instance and the tap interface on the controller, I see arp requests going out of the instance, being received on the tap interface, the tap interface sending a reply, but the reply never reaching the instance.</div>
<div><br></div><div>However, I have found that if I create a bridge with the same MAC as the interface that I'm adding to the bridge, traffic flows correctly:</div><div><br></div><div>ovs-vsctl set bridge br-eth0 other-config:hwaddr=aa:bb:cc:00:11:22</div>
<div><br></div><div>My best guess is that there's something (L2) blocking the flow of traffic, but I'm not exactly sure where to start looking. I think it's safe to assume that Open vSwitch on the OpenStack servers is doing the blocking but I think it's Quantum that's implementing the blocking since if I use Open vSwitch with nova-network, this problem doesn't happen.</div>
<div><br></div><div>Does anyone have any pointers? Or even a fix?<br></div><div><br></div><div>Thanks,</div><div>Joe</div><span><font color="#888888"><div><br></div><div>-- <br>Joe Topjian<div>Systems Administrator</div>
<div>Cybera Inc.</div><div><br></div><div><a href="http://www.cybera.ca" target="_blank">www.cybera.ca</a></div><div><br></div><div><font color="#666666"><span>Cybera</span><span> is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.</span></font></div>
</div></font></span></div>
<br></div></div>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Joe Topjian<div>Systems Administrator</div><div>Cybera Inc.</div><div><br></div><div><a href="http://www.cybera.ca" target="_blank">www.cybera.ca</a></div>
<div><br></div><div><font color="#666666"><span>Cybera</span><span> is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.</span></font></div>
</div>