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

Tue Nov 20 22:48:49 PST 2012

Hello World,

Sorry for the excess emails. My email client went crazy. I will pay much
more attention in the future.
Back to OpenNebula and OpenvSwitch drivers Mr. Ben Pfaff put it nicely

  It is important to understand that a "fake bridge" is neither an
OpenvSwitch bridge nor an
  OpenFlow switch. Thus, you cannot use them in most contexts where an Open
vSwitch
  bridge or an OpenFlow switch is required. I am surprised that the word
"fake" in the name
  does not make this clear.

Using the bridge the "fake bridge" is part of, it works:

```
$ sudo /usr/bin/ovs-ofctl dump-ports br0 vnet0
OFPST_PORT reply (xid=0x1): 1 ports
  port 17: rx pkts=680611, bytes=204556006, drop=0, errs=0, frame=0,
over=0, crc=0
              tx pkts=675160, bytes=352172599, drop=0, errs=0, coll=0
````

I am going to keep current with libvirt and drop the bridge compatibility
layer out of the ecuation.
That's the reason I have "fake bridges" to begin with.

Thanks. Cheers and Goodwill

On Tue, Nov 20, 2012 at 12:01 PM, Valentin Bud <valentin.bud at gmail.com>wrote:

> 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
>

-- 
w: http://databus.ro/blog
in: http://www.linkedin.com/pub/valentin-bud/9/881/830
t: https://twitter.com/valentinbud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20121121/6d430189/attachment-0002.htm>