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 >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
