Re: [Openstack] Nested Open vSwitch Bridges
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-0004-fa163e3ec9b3 e8cd7fa5-2de9-cfe1-f24f-8a449043c6f3 nova-instance-instance-0005-fa163ed87bff 16e11cd9-6e17-3c91-6776-e3bffc70e94b nova-instance-instance-0006-fa163ecd666a c5ba020f-6b6f-d511-8ee1-2e2b49497431 nova-instance-instance-0007-fa163e1d4e38 2d085283-a4bf-79f8-80f1-20498b8cc475 nova-instance-instance-0018-fa163ee1842c 7d4bb9f1-597e-2a36-e340-45ec710b4481 nova-instance-instance-0088-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.topj...@cybera.ca 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 sorla...@nicira.comwrote: 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.comwrote: 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.
Re: [Openstack] Nested Open vSwitch Bridges
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 thul...@gmail.com 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-0004-fa163e3ec9b3 e8cd7fa5-2de9-cfe1-f24f-8a449043c6f3 nova-instance-instance-0005-fa163ed87bff 16e11cd9-6e17-3c91-6776-e3bffc70e94b nova-instance-instance-0006-fa163ecd666a c5ba020f-6b6f-d511-8ee1-2e2b49497431 nova-instance-instance-0007-fa163e1d4e38 2d085283-a4bf-79f8-80f1-20498b8cc475 nova-instance-instance-0018-fa163ee1842c 7d4bb9f1-597e-2a36-e340-45ec710b4481 nova-instance-instance-0088-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.topj...@cybera.ca 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 sorla...@nicira.comwrote: 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
[Openstack] Nested Open vSwitch Bridges
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
Re: [Openstack] Nested Open vSwitch Bridges
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
Re: [Openstack] Nested Open vSwitch Bridges
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.comwrote: 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
Re: [Openstack] Nested Open vSwitch Bridges
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.comwrote: 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
Re: [Openstack] 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 sorla...@nicira.comwrote: 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.comwrote: 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 -- 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
