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