Hello World,<div><br></div><div>Sorry for the excess emails. My email client went crazy. I will pay much more attention in the future.</div><div>Back to OpenNebula and OpenvSwitch drivers Mr. Ben Pfaff put it nicely</div><div>
<br></div><div> It is important to understand that a "fake bridge" is neither an OpenvSwitch bridge nor an </div><div> OpenFlow switch. Thus, you cannot use them in most contexts where an Open vSwitch </div><div>
bridge or an OpenFlow switch is required. I am surprised that the word "fake" in the name </div><div> does not make this clear.</div><div><br></div><div>Using the bridge the "fake bridge" is part of, it works:</div>
<div><br></div><div>```</div><div>$ sudo /usr/bin/ovs-ofctl dump-ports br0 vnet0</div><div><div>OFPST_PORT reply (xid=0x1): 1 ports</div><div> port 17: rx pkts=680611, bytes=204556006, drop=0, errs=0, frame=0, over=0, crc=0</div>
<div> tx pkts=675160, bytes=352172599, drop=0, errs=0, coll=0</div></div><div>````</div><div><br></div><div>I am going to keep current with libvirt and drop the bridge compatibility layer out of the ecuation.</div>
<div>That's the reason I have "fake bridges" to begin with.</div><div><br></div><div>Thanks. Cheers and Goodwill</div><div><br></div><div>On Tue, Nov 20, 2012 at 12:01 PM, Valentin Bud <span dir="ltr"><<a href="mailto:valentin.bud@gmail.com" target="_blank">valentin.bud@gmail.com</a>></span> wrote:</div>
<div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Hi Ruben,<br>
<br>
On Tue, Nov 13, 2012 at 11:05:06AM +0100, Ruben S. Montero wrote:<br>
</div><div class="im">> Hi<br>
><br>
> The 3.8 version of the Openvswitch drivers use openflows as there are some<br>
> incompatibility issues when using iptables and ovswitch. Note that there<br>
> are some filtering limitations (compared to the iptables) regarding the<br>
> definition of TCP/UDP port ranges.<br>
><br>
> Mon Nov 12 15:17:44 2012 [VMM][D]: Message received: LOG E 216 post:<br>
> > Command "sudo /usr/bin/ovs-ofctl add-flow vlan5<br>
> > in_port=,dl_src=02:00:0a:80:05:32,priority=40000,actions=normal" failed.<br>
> ><br>
><br>
> This may be some kind of incompatibility of the ovswitch version of your<br>
> installation and the drivers. The problem here is the empty in_port. Can<br>
> you deploy the VM by hand and send the output of (executed as oneadmin):<br>
><br>
> sudo /usr/bin/ovs-ofctl dump-ports vlan5 <VM_tap_interface><br>
<br>
</div><div class="im">I receive the following message:<br>
```<br>
$ sudo /usr/bin/ovs-ofctl dump-ports vlan5 vnet0<br>
</div><div class="im">ovs-ofctl: vlan5 is not a bridge or a socket<br>
</div><div class="im">```<br>
<br>
OpenNebula runs on a CentOS 6.3 host and is built with Ceph patches.<br>
OpenvSwitch is at version 1.8.0.<br>
<br>
```<br>
$ uname -a<br>
Linux <a href="http://andreea.xxx.com" target="_blank">andreea.xxx.com</a> 2.6.32-279.9.1.el6.x86_64 #1 SMP Tue Sep<br>
25 21:43:11 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux<br>
<br>
$ ovs-vsctl --version<br>
ovs-vsctl (Open vSwitch) 1.8.0<br>
Compiled Sep 3 2012 23:10:42<br>
```<br>
<br>
</div>I've also posted a question to OpenvSwitch Discuss [1], because I think it's related.<br>
<div class="im"><br>
><br>
><br>
><br>
><br>
> ><br>
> > The vlan5 port on this particular switch is a `fake bridge`. Linux<br>
> > bridge compatibility layer is enabled as requested by the docs [1].<br>
> ><br>
> > ```<br>
> > $ ps aux | grep openvswitch<br>
><br>
><br>
> All seems ok here<br>
><br>
><br>
> ><br>
> > The OpenFlow default rules employed by OpenNebula state on the doc<br>
> > [2] page the following:<br>
> ><br>
> > `These rules prevent any traffic to come out of the port the MAC<br>
> > address has changed.`<br>
> ><br>
> > Does this mean that traffic coming out of the port OpenNebula just<br>
> > created on the switch is denied/dropped? Or does it mean that traffic<br>
> > with the source MAC address of the VM should only come in on the<br>
> > specified port, the newly added port for the VM?<br>
> ><br>
><br>
> The later, any traffic with source MAC address different from one assigned<br>
> to the VM is filtered out. To prevent a user to change the VM MAC from the<br>
> guest...<br>
><br>
><br>
<br>
</div><div class="im">This is one thing you'd want to keep around. Allowing a user to change<br>
it's MAC address has some security implications. I think this is a safe<br>
measure against MITM attacks. This way the attacker cannot advertise a<br>
bogus MAC address.<br>
<br>
> ><br>
</div><div class="im">> > Maybe I'm wrong, but at a glance flows can improve security and thus are<br>
> > a huge improvement to OpenNebula. Do you, devs and users, think that it<br>
> > would be better to separate the flow definition from code? For now if we<br>
> > want to add flow rules we have to modify<br>
> > `/var/lib/one/remotes/vnm/ovswitch/OpenvSwitch.rb`. I think it would be<br>
> > wise to have separate files with rules based on the users' need.<br>
><br>
><br>
> > `ovs-ofctl` can add flows directly from a file so it wouldn't be very<br>
> > hard, I guess, to separate the flows from the code. Of course one can do<br>
> > this by himself by modifying `post`.<br>
> ><br>
><br>
> Yes, this may be a good idea. Use a filter file with some template engine<br>
> (ERB, haml...)<br>
><br>
<br>
</div><div class="im">Where would you store this files in the current directory layout of<br>
OpenNebula?<br>
<br>
I would take this as an opportunity to learn a little bit of Ruby and<br>
try to implement the above feature. Can you please tell me where should<br>
I start?<br>
<br>
I think this is a very good idea. Do you think it would be a good ideea<br>
to store the files as JSON, so automation tools can drop a file in a<br>
`conf.d` like directory, at VM boot?<br>
<br>
><br>
> ><br>
</div><div class="im">> > One more thing, why does OpenNebula need the Linux bridge compatibility<br>
> > layer enabled?<br>
> ><br>
><br>
> This is basically a requirement from the hypervisor that uses brctl<br>
> addif... KVM (through libvirt) supports Openvswitch without compatibility<br>
> layer since version 0.9.11. We opted to preserve this requirement and<br>
> remove it in future versions (and add <virtualport> for NICs). Note that<br>
> the driver itself does not require the compatibility layer, as it uses<br>
> openvswitch commands.<br>
<br>
</div><div class="im">If I understand correctly I can disable bridge compatibility. Do you<br>
think it would be wise to stay current with latest libvirt Official<br>
Releases?<br>
<br>
</div>Thanks for helping.<br>
<br>
[1]: <a href="http://openvswitch.org/pipermail/discuss/2012-November/008422.html" target="_blank">http://openvswitch.org/pipermail/discuss/2012-November/008422.html</a><br>
<br>
Cheers and Goodwill,<br>
v<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>w: <a href="http://databus.ro/blog" target="_blank">http://databus.ro/blog</a><div>in: <a href="http://www.linkedin.com/pub/valentin-bud/9/881/830" target="_blank">http://www.linkedin.com/pub/valentin-bud/9/881/830</a></div>
<div>t: <a href="https://twitter.com/valentinbud" target="_blank">https://twitter.com/valentinbud</a></div><br>
</div>