← Back to team overview

openstack team mailing list archive

Re: Nested Open vSwitch Bridges

 

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 <sorlando@xxxxxxxxxx>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 <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
>>>
>>>
>>
>


-- 
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.

Follow ups

References