<div dir="ltr">Hi Oriol,<div><br></div><div style>I have created this bug report: <a href="http://dev.opennebula.org/issues/1787">http://dev.opennebula.org/issues/1787</a></div><div style><br></div><div style>cheers,<br>Jaime</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 21, 2013 at 4:57 PM, Oriol Martí <span dir="ltr"><<a href="mailto:omarti@cesca.cat" target="_blank">omarti@cesca.cat</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi Simon, <br>
<br>
I don't have any reason for using the same subnet, but if you have
different users and they don't see the virtual networks created by
other users, this situation can occur.<br>
It's very common to create a private VNET and assign
<a href="http://192.168.1.0/24" target="_blank">192.168.1.0/24</a> for example, then if the same mac VMs are in the
same node, the filtering rules are applied to the two nodes...<br>
<br>
Cheers,<br>
<br>
;)riol<div><div class="h5"><br>
<br>
On 02/21/2013 03:28 PM, Simon Boulet wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">Hi Oriol,
<div><br>
</div>
<div>> this occurs when you create 2 VNETs with the same
range of IPs,</div>
<div><br>
</div>
<div>Is there any particular reasons for using the same
subnet on two different network?</div>
<div><br>
</div>
<div>Simon</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Feb 21, 2013 at 5:16 AM,
Oriol Martí <span dir="ltr"><<a href="mailto:omarti@cesca.cat" target="_blank">omarti@cesca.cat</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi Jaime,<br>
<br>
continuing with the openvswitch driver, I think I've
found a bug, this occurs when you create 2 VNETs with
the same range of IPs, then if ONE decides to put two
VMs in the same node you have the same MAC for two
VMs, the problem arrives if you have defined BLACK or
WHITE ports or ICMP rules, then you will have all the
dropped ports to the two machines. This is caused by
the rules with ovs-ofctl are applied by MAC, then as
you have the same MAC in different VMs, the
openvswitch does not know which port is referring and
it applies the rule for the two ports.<br>
<br>
I've resolved the problem by adding the tag dl_vlan
when you are adding the rule, with this tag you
specify the vlan tag that the port you want to filter
has. If you don't have tags in the vlans I think this
problem does not have solution, but in my case, I have
modified the sunstone interface to don't show the VLAN
select and is sending "YES"<br>
<br>
If you think this can be a bug, I can upload the
situation and the solution in the issue tracker.<br>
<br>
In a few days I'm going to make the white and black
ports full functionality.<br>
Attached you can find the file
/var/lib/one/remotes/vnm/ovswitch/OpenvSwitch.rb<br>
<br>
Cheers,<br>
<br>
The diff between the original and the new file:<br>
55a56,61<br>
> if @nic[:vlan_id]<br>
> vlan = @nic[:vlan_id]<br>
> else<br>
> vlan = CONF[:start_vlan] +
@nic[:network_id].to_i<br>
> end<br>
> <br>
72,76c78<br>
< if @nic[:vlan] == "YES"<br>
<
add_flow("tcp,dl_dst=#{@nic[:mac]},tp_dst=#{p},dl_vlan=#{vlan}",:drop)<br>
< else
<div><br>
<
add_flow("tcp,dl_dst=#{@nic[:mac]},tp_dst=#{p}",:drop)<br>
</div>
< end<br>
---
<div><br>
>
add_flow("tcp,dl_dst=#{@nic[:mac]},tp_dst=#{p}",:drop)<br>
</div>
85,89c87<br>
< if @nic[:vlan] == "YES"<br>
<
add_flow("udp,dl_dst=#{@nic[:mac]},tp_dst=#{p},dl_vlan=#{vlan}",:drop)<br>
< else<br>
<
add_flow("udp,dl_dst=#{@nic[:mac]},tp_dst=#{p}",:drop)<br>
< end<br>
---<br>
>
add_flow("udp,dl_dst=#{@nic[:mac]},tp_dst=#{p}",:drop)<br>
97,101c95<br>
< if @nic[:vlan] == "YES"<br>
<
add_flow("icmp,dl_dst=#{@nic[:mac]},dl_vlan=#{vlan}",:drop)<br>
< else<br>
<
add_flow("icmp,dl_dst=#{@nic[:mac]}",:drop)<br>
< end<br>
---<br>
>
add_flow("icmp,dl_dst=#{@nic[:mac]}",:drop)<br>
147,154d140<br>
< <br>
< def vlan<br>
< if @nic[:vlan_id]<br>
< return @nic[:vlan_id] <br>
< else<br>
< return CONF[:start_vlan] +
@nic[:network_id].to_i<br>
< end<br>
< end <br>
<div>
<div> <br>
<br>
On 02/19/2013 11:19 AM, Jaime Melis wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">Hi Oriol
<div><br>
</div>
<div>I don't know if creating that many rules
will impact Open vSwitch's performance, I
guess it's something you could ask in the Open
vSwitch mailing list, or give it a try
yourself and see if it works fine.</div>
<div><br>
</div>
<div>In any case I think that the approach you
described above is the correct one.</div>
<div><br>
</div>
<div>cheers,<br>
Jaime</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote"> On Mon, Feb 18, 2013
at 1:24 PM, Oriol Martí <span dir="ltr"><<a href="mailto:omarti@cesca.cat" target="_blank">omarti@cesca.cat</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi Jaime, <br>
looking at the file
/var/lib/one/remotes/vnm/ovswitch/OpenvSwitch.rb<br>
My idea is to add that black_ports look
for : and do the command<br>
add_flow("tcp,dl_dst=#{@nic[:mac]},tp_dst=#{p}",:drop)<br>
for every port in the range.<br>
With the white_port, the normal
behaviour is all closed but the
indicated ports? my idea is to do the
drop for all the ports but the indicated
ports.<br>
Is this correct? I'm not sure if this
big amount of rules can add extra load
to the node or it can derive to
problems...<br>
<br>
Thanks,
<div>
<div><br>
<br>
On 02/18/2013 12:33 PM, Jaime Melis
wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">Hi Oriol,
<div><br>
</div>
<div>yes, WHITE_PORTS is not
implement, and neither are port
ranges with semi-colon:</div>
<div><a href="http://opennebula.org/documentation:rel3.8:openvswitch#network_filtering" target="_blank">http://opennebula.org/documentation:rel3.8:openvswitch#network_filtering</a><br>
</div>
<div><br>
</div>
<div>The reason is because
iptables filters won't work with
Open vSwitch, so port filtering
is implemented via OpenFlow. If
you find a way to improve the
drivers it would be really nice.
Let me know if I can help in any
way.</div>
<div><br>
</div>
<div>cheers,<br>
Jaime</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon,
Feb 18, 2013 at 11:52 AM, Oriol
Martí <span dir="ltr"><<a href="mailto:omarti@cesca.cat" target="_blank">omarti@cesca.cat</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
I'm deploying the Open vswitch
driver and when I create one
VM with the BLACK and
WHITE_PORTS it doesn't work.<br>
<br>
I've seen the code and I'm not
sure, but I think that white
port is not implemented and
the black ports only is doing
a strip for "," not by ":",
then if you want to configure
a VM with all the ports closed
and only opened the 80 is very
difficult to do because you
would have to write all the
ports, one by one, and is
impossible to indicate a range
of ports like 80:65535<br>
<br>
I'm thinking to write the code
necessary to do that, but I'm
not sure, because I don't know
the reason why is not
finished.... Does anybody know
something about that?<br>
<br>
Best regards,<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org" target="_blank">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
</blockquote>
</div>
<br>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
Jaime Melis<br>
Project Engineer<br>
OpenNebula - The Open Source Toolkit
for Cloud Computing<br>
<a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a>
| <a href="mailto:jmelis@opennebula.org" target="_blank">jmelis@opennebula.org</a>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Jaime Melis<br>
Project Engineer<br>
OpenNebula - The Open Source Toolkit for Cloud
Computing<br>
<a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:jmelis@opennebula.org" target="_blank">jmelis@opennebula.org</a> </div>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org" target="_blank">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
<br>
</div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Jaime Melis<br>Project Engineer<br>OpenNebula - The Open Source Toolkit for Cloud Computing<br><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:jmelis@opennebula.org" target="_blank">jmelis@opennebula.org</a>
</div>