openstack team mailing list archive

[Salvatore Orlando <sorlando@xxxxxxxxxx>]

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 <arosen@xxxxxxxxxx> 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 <sorlando@xxxxxxxxxx>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.topjian@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>