Thank you both for the information. 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.
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. Thanks again, Joe On Tue, Apr 30, 2013 at 5:57 PM, Salvatore Orlando <sorla...@nicira.com>wrote: > I was not aware that security groups for OVS already enforced anti > spoofing rules. > That's good to know. > > Salvatore > > > On 1 May 2013 00:55, Aaron Rosen <aro...@nicira.com> wrote: > >> 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). >> >> Aaron >> >> >> On Tue, Apr 30, 2013 at 4:25 PM, Salvatore Orlando >> <sorla...@nicira.com>wrote: >> >>> Hi Joe, >>> >>> are you using the OVS plugin with GRE overlays? >>> 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] >>> >>> 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. >>> >>> Salvatore >>> >>> [1] >>> https://github.com/openstack/quantum/blob/master/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py#L448 >>> >>> >>> >>> On 30 April 2013 22:08, Joe Topjian <joe.topj...@cybera.ca> wrote: >>> >>>> Hello, >>>> >>>> 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. >>>> >>>> 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: >>>> >>>> ovs-vsctl add-br br-eth0 >>>> ovs-vsctl add-port br-eth0 eth0 >>>> (swap IPs from eth0 to br-eth0, kill dhcp, etc etc) >>>> >>>> Traffic isn't flowing properly, though. >>>> >>>> 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. >>>> >>>> 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: >>>> >>>> ovs-vsctl set bridge br-eth0 other-config:hwaddr=aa:bb:cc:00:11:22 >>>> >>>> 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. >>>> >>>> Does anyone have any pointers? Or even a fix? >>>> >>>> Thanks, >>>> Joe >>>> >>>> -- >>>> Joe Topjian >>>> Systems Administrator >>>> Cybera Inc. >>>> >>>> www.cybera.ca >>>> >>>> Cybera is a not-for-profit organization that works to spur and support >>>> innovation, for the economic benefit of Alberta, through the use >>>> of cyberinfrastructure. >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : openstack@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> > -- Joe Topjian Systems Administrator Cybera Inc. www.cybera.ca Cybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp