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 wrote:
> And if you use libvirt virt driver, the hypervisor (libvirt+KVM in my
> case) adds anti MAC and IP spoofi
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 al
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 ultim
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 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
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, S
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
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 rea
7 matches
Mail list logo
