[one-users] BLACK and WHITE_PORTS with open vswitch

Thu Feb 21 06:28:33 PST 2013

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> 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
>
>
>
> _______________________________________________
> Users mailing list
> 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/e33bfbc4/attachment-0002.htm>