[one-users] BLACK and WHITE_PORTS with open vswitch

Jaime Melis jmelis at opennebula.org
Thu Feb 21 08:31:54 PST 2013


Hi Oriol,

you are totally right. That's an important bug that needs to be taken care
of. Your contributions are very welcome. Can you upload them to the issue
tracker?

thanks!

cheers,
Jaime



On Thu, Feb 21, 2013 at 11:16 AM, Oriol Martí <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> 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> 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
>>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>>
>>
>>
>>
>>  --
>> Jaime Melis
>> Project Engineer
>> OpenNebula - The Open Source Toolkit for Cloud Computing
>> www.OpenNebula.org | jmelis at opennebula.org
>>
>>
>>
>
>
>  --
> Jaime Melis
> Project Engineer
> OpenNebula - The Open Source Toolkit for Cloud Computing
> www.OpenNebula.org | jmelis at opennebula.org
>
>
>


-- 
Jaime Melis
Project Engineer
OpenNebula - The Open Source Toolkit for Cloud Computing
www.OpenNebula.org | jmelis at opennebula.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20130221/d56b46b2/attachment.htm>


More information about the Users mailing list