[one-users] OpenNebula 3.8.1 ovswitch ovs-ofctl bad syntax for in_port

[Valentin Bud]

Hi Ruben,

On Tue, Nov 13, 2012 at 11:05:06AM +0100, Ruben S. Montero wrote:
> Hi
> 
> The 3.8 version of the Openvswitch drivers use openflows as there are some
> incompatibility issues when using iptables and ovswitch. Note that there
> are some filtering limitations (compared to the iptables) regarding the
> definition of TCP/UDP port ranges.
> 
> Mon Nov 12 15:17:44 2012 [VMM][D]: Message received: LOG E 216 post:
> > Command "sudo /usr/bin/ovs-ofctl add-flow vlan5
> > in_port=,dl_src=02:00:0a:80:05:32,priority=40000,actions=normal" failed.
> >
> 
> This may be some kind of incompatibility of the ovswitch version of your
> installation and the drivers. The problem here is the empty in_port. Can
> you deploy the VM by hand and send the output of (executed as oneadmin):
> 
> sudo /usr/bin/ovs-ofctl dump-ports vlan5 <VM_tap_interface>

I receive the following message:
```
$ sudo /usr/bin/ovs-ofctl dump-ports vlan5 vnet0
ovs-ofctl: vlan5 is not a bridge or a socket
``` 

OpenNebula runs on a CentOS 6.3 host and is built with Ceph patches.
OpenvSwitch is at version 1.8.0.

```
$ uname -a 
Linux andreea.xxx.com 2.6.32-279.9.1.el6.x86_64 #1 SMP Tue Sep
25 21:43:11 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ ovs-vsctl --version
ovs-vsctl (Open vSwitch) 1.8.0
Compiled Sep  3 2012 23:10:42
```

I've also posted a question to OpenvSwitch Discuss [1], because I think it's related.

> 
> 
> 
> 
> >
> > The vlan5 port on this particular switch is a `fake bridge`. Linux
> > bridge compatibility layer is enabled as requested by the docs [1].
> >
> > ```
> > $ ps aux | grep openvswitch
> 
> 
> All seems ok here
> 
> 
> >
> > The OpenFlow default rules employed by OpenNebula state on the doc
> > [2] page the following:
> >
> >     `These rules prevent any traffic to come out of the port the MAC
> >     address has changed.`
> >
> > Does this mean that traffic coming out of the port OpenNebula just
> > created on the switch is denied/dropped? Or does it mean that traffic
> > with the source MAC address of the VM should only come in on the
> > specified port, the newly added port for the VM?
> >
> 
> The later, any traffic with source MAC address different from one assigned
> to the VM is filtered out. To prevent a user to change the VM MAC from the
> guest...
> 
> 

This is one thing you'd want to keep around. Allowing a user to change
it's MAC address has some security implications. I think this is a safe
measure against MITM attacks. This way the attacker cannot advertise a
bogus MAC address. 

> >
> > Maybe I'm wrong, but at a glance flows can improve security and thus are
> > a huge improvement to OpenNebula. Do you, devs and users, think that it
> > would be better to separate the flow definition from code? For now if we
> > want to add flow rules we have to modify
> > `/var/lib/one/remotes/vnm/ovswitch/OpenvSwitch.rb`. I think it would be
> > wise to have separate files with rules based on the users' need.
> 
> 
> > `ovs-ofctl` can add flows directly from a file so it wouldn't be very
> > hard, I guess, to separate the flows from the code. Of course one can do
> > this by himself by modifying `post`.
> >
> 
> Yes, this may be a good idea. Use a filter file with some template engine
> (ERB, haml...)
> 

Where would you store this files in the current directory layout of
OpenNebula? 

I would take this as an opportunity to learn a little bit of Ruby and
try to implement the above feature. Can you please tell me where should
I start?

I think this is a very good idea. Do you think it would be a good ideea
to store the files as JSON, so automation tools can drop a file in a
`conf.d` like directory, at VM boot?

> 
> >
> > One more thing, why does OpenNebula need the Linux bridge compatibility
> > layer enabled?
> >
> 
> This is basically a requirement from the hypervisor that uses brctl
> addif... KVM (through libvirt) supports Openvswitch without compatibility
> layer since version 0.9.11. We opted to preserve this requirement and
> remove it in future versions (and add <virtualport> for NICs). Note that
> the driver itself does not require the compatibility layer, as it uses
> openvswitch commands.

If I understand correctly I can disable bridge compatibility. Do you
think it would be wise to stay current with latest libvirt Official
Releases?

Thanks for helping.

[1]: http://openvswitch.org/pipermail/discuss/2012-November/008422.html

Cheers and Goodwill,
v