[one-users] BLACK and WHITE_PORTS with open vswitch

Oriol Martí omarti at cesca.cat
Thu Feb 21 07:57:38 PST 2013


Hi Simon,

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.
It's very common to create a private VNET and assign 192.168.1.0/24 for 
example, then if the same mac VMs are in the same node, the filtering 
rules are applied to the two nodes...

Cheers,

;)riol

On 02/21/2013 03:28 PM, Simon Boulet wrote:
> Hi Oriol,
>
> >  this occurs when you create 2 VNETs with the same range of IPs,
>
> Is there any particular reasons for using the same subnet on two 
> different network?
>
> Simon
>
> On Thu, Feb 21, 2013 at 5:16 AM, Oriol Martí <omarti at cesca.cat 
> <mailto:omarti at cesca.cat>> wrote:
>
>     Hi Jaime,
>
>     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.
>
>     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"
>
>     If you think this can be a bug, I can upload the situation and the
>     solution in the issue tracker.
>
>     In a few days I'm going to make the white and black ports full
>     functionality.
>     Attached you can find the file
>     /var/lib/one/remotes/vnm/ovswitch/OpenvSwitch.rb
>
>     Cheers,
>
>     The diff between the original and the new file:
>     55a56,61
>     >         if @nic[:vlan_id]
>     >             vlan = @nic[:vlan_id]
>     >         else
>     >             vlan = CONF[:start_vlan] + @nic[:network_id].to_i
>     >         end
>     >
>     72,76c78
>     <                     if @nic[:vlan] == "YES"
>     <
>     add_flow("tcp,dl_dst=#{@nic[:mac]},tp_dst=#{p},dl_vlan=#{vlan}",:drop)
>     <                     else
>
>     < add_flow("tcp,dl_dst=#{@nic[:mac]},tp_dst=#{p}",:drop)
>     <                     end
>     ---
>
>     > add_flow("tcp,dl_dst=#{@nic[:mac]},tp_dst=#{p}",:drop)
>     85,89c87
>     <                     if @nic[:vlan] == "YES"
>     <
>     add_flow("udp,dl_dst=#{@nic[:mac]},tp_dst=#{p},dl_vlan=#{vlan}",:drop)
>     <                     else
>     < add_flow("udp,dl_dst=#{@nic[:mac]},tp_dst=#{p}",:drop)
>     <                     end
>     ---
>     > add_flow("udp,dl_dst=#{@nic[:mac]},tp_dst=#{p}",:drop)
>     97,101c95
>     <                 if @nic[:vlan] == "YES"
>     < add_flow("icmp,dl_dst=#{@nic[:mac]},dl_vlan=#{vlan}",:drop)
>     <                 else
>     < add_flow("icmp,dl_dst=#{@nic[:mac]}",:drop)
>     <                 end
>     ---
>     > add_flow("icmp,dl_dst=#{@nic[:mac]}",:drop)
>     147,154d140
>     <
>     <     def vlan
>     <         if @nic[:vlan_id]
>     <             return @nic[:vlan_id]
>     <         else
>     <             return CONF[:start_vlan] + @nic[:network_id].to_i
>     <         end
>     <     end
>
>
>     On 02/19/2013 11:19 AM, Jaime Melis wrote:
>>     Hi Oriol
>>
>>     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.
>>
>>     In any case I think that the approach you described above is the
>>     correct one.
>>
>>     cheers,
>>     Jaime
>>
>>
>>     On Mon, Feb 18, 2013 at 1:24 PM, Oriol Martí <omarti at cesca.cat
>>     <mailto:omarti at cesca.cat>> wrote:
>>
>>         Hi Jaime,
>>         looking at the file
>>         /var/lib/one/remotes/vnm/ovswitch/OpenvSwitch.rb
>>         My idea is to add that black_ports look for : and do the command
>>         add_flow("tcp,dl_dst=#{@nic[:mac]},tp_dst=#{p}",:drop)
>>         for every port in the range.
>>         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.
>>         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...
>>
>>         Thanks,
>>
>>
>>         On 02/18/2013 12:33 PM, Jaime Melis wrote:
>>>         Hi Oriol,
>>>
>>>         yes, WHITE_PORTS is not implement, and neither are port
>>>         ranges with semi-colon:
>>>         http://opennebula.org/documentation:rel3.8:openvswitch#network_filtering
>>>
>>>         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.
>>>
>>>         cheers,
>>>         Jaime
>>>
>>>
>>>         On Mon, Feb 18, 2013 at 11:52 AM, Oriol Martí
>>>         <omarti at cesca.cat <mailto:omarti at cesca.cat>> wrote:
>>>
>>>             Hi,
>>>             I'm deploying the Open vswitch driver and when I create
>>>             one VM with the BLACK and WHITE_PORTS it doesn't work.
>>>
>>>             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
>>>
>>>             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?
>>>
>>>             Best regards,
>>>
>>>             _______________________________________________
>>>             Users mailing list
>>>             Users at lists.opennebula.org
>>>             <mailto:Users at lists.opennebula.org>
>>>             http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>>
>>>
>>>
>>>
>>>         -- 
>>>         Jaime Melis
>>>         Project Engineer
>>>         OpenNebula - The Open Source Toolkit for Cloud Computing
>>>         www.OpenNebula.org <http://www.OpenNebula.org> |
>>>         jmelis at opennebula.org <mailto:jmelis at opennebula.org> 
>>
>>
>>
>>
>>     -- 
>>     Jaime Melis
>>     Project Engineer
>>     OpenNebula - The Open Source Toolkit for Cloud Computing
>>     www.OpenNebula.org <http://www.OpenNebula.org> |
>>     jmelis at opennebula.org <mailto:jmelis at opennebula.org>
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opennebula.org <mailto:Users at lists.opennebula.org>
>     http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20130221/6a2317cd/attachment-0001.htm>


More information about the Users mailing list