openstack team mailing list archive

[Joe Topjian <joe.topjian@xxxxxxxxx>]

I'm not sure how effective these rules are. I've been able to use
OVS+nova-network+libvirt to create nested bridges without issues.


On Thu, May 2, 2013 at 12:53 AM, Édouard Thuleau <thuleau@xxxxxxxxx> wrote:

> And if you use libvirt virt driver, the hypervisor (libvirt+KVM in my
> case) adds anti MAC and IP spoofing rules on VNICs of VM:
>
> $ virsh nwfilter-list
> UUID                                  Name
> ----------------------------------------------------------------
> 991dbd1a-373b-a005-57b2-5b1f4107f653  allow-arp
> aefdae18-56e8-4e67-c8f1-cc826e2c519c  allow-dhcp
> f1e80828-1b4b-dcb3-4136-faaf5beab9e2  allow-dhcp-server
> 9e497c96-ec4a-4ad8-fcbb-d2917e3af70a  allow-incoming-ipv4
> 4d998884-5870-8956-5585-d34f77231e3e  allow-ipv4
> 7a4233d3-1fa8-6eb1-f2e8-3e55f773da0d  clean-traffic
> fae01ed3-2bd5-e6b4-a63e-daa336655c20  no-arp-ip-spoofing
> bf61b4b4-f844-6c36-9bb7-6245b642b0cb  no-arp-mac-spoofing
> 04cc5d54-08a0-31ca-4b5e-79a2e96d276b  no-arp-spoofing
> 255d63a3-12a7-32b9-dffb-a2d61c8fcb39  no-ip-multicast
> a0e9b6f3-e099-2b0b-7d4b-69e63587fa39  no-ip-spoofing
> 83145355-39d1-9dce-4012-3032c110cf82  no-mac-broadcast
> 653c47ed-48f0-25ea-bf18-1153a58d3773  no-mac-spoofing
> cc460af0-ee60-7ca8-c09e-a074490711ac  no-other-l2-traffic
> 5df592f3-dcff-e0f3-73ac-d2eb3baeda11  no-other-rarp-traffic
> 891e4787-e5c0-d59b-cbd6-41bc3c6b36fc  nova-allow-dhcp-server
> 418f4ad6-d997-b483-15d9-c7c2c21b4eba  nova-base
> fdc1ee23-05a1-0303-6d24-8a300bd57f21
>  nova-instance-instance-00000004-fa163e3ec9b3
> e8cd7fa5-2de9-cfe1-f24f-8a449043c6f3
>  nova-instance-instance-00000005-fa163ed87bff
> 16e11cd9-6e17-3c91-6776-e3bffc70e94b
>  nova-instance-instance-00000006-fa163ecd666a
> c5ba020f-6b6f-d511-8ee1-2e2b49497431
>  nova-instance-instance-00000007-fa163e1d4e38
> 2d085283-a4bf-79f8-80f1-20498b8cc475
>  nova-instance-instance-00000018-fa163ee1842c
> 7d4bb9f1-597e-2a36-e340-45ec710b4481
>  nova-instance-instance-00000088-fa163ef641ad
> 79ef4d25-ff42-fd63-f34b-fc1079c391b3  nova-nodhcp
> c5ac3035-ac46-3870-ff5c-296b5f4221d3  nova-vpn
> b615cae6-4ca8-882f-42e1-9de541e4844b  qemu-announce-self
> b34d17b0-30d6-75c4-19d0-e636d1f99160  qemu-announce-self-rarp
>
> The virt driver is control by Nova, so is that Nova should be responsible
> for network security? Perhaps it could be disabled? But if we disable it,
> is that Quantum takes good care?
>
> Édouard.
>
>
> On Wed, May 1, 2013 at 7:14 AM, Joe Topjian <joe.topjian@xxxxxxxxx> wrote:
>
>> 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.
>>
>> _______________________________________________
>> 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.