[ovs-discuss] [ovs-dev] can OVS conntrack support IP list like this: actions=ct(commit, table=0, zone=1, nat(dst=220.0.0.3, 220.0.0.7, 220.0.0.123))?

Darrell Ball dlu998 at gmail.com
Thu Nov 7 16:52:48 UTC 2019


On Thu, Nov 7, 2019 at 8:05 AM Darrell Ball <dlu998 at gmail.com> wrote:

>
>
> On Wed, Nov 6, 2019 at 5:01 PM Yi Yang (杨燚)-云服务集团 <yangyi01 at inspur.com>
> wrote:
>
>> Thanks Darrell, I didn’t receive your second reply, I saw it in
>> mail.openvswitch.org.
>>
>>
>>
>>>>
>> probably, you should give an example of what you mean by above
>>
>> I am not sure you are meaning to say that you want to specify an L4 port
>> in
>>
>> your
>>
>> snat action rule or not; you will want to use ephemeral ports by not
>>
>> specifying a
>>
>> specific port in most cases
>>
>>>>
>>
>>
>> For SNAT, we don’t specify port, just use default port range
>> “1024-65535”), but for internal source IPs, i.e. floating IPs, they are
>> discrete in most cases because some floating IPs needn’t access Internet,
>> for public IPs, so are they. For public IPs, maybe they are from different
>> telecom carriers, we prefer egress traffic can be distributed on several
>> BGP lines.
>>
>
>>
>>
>> table=0,ip,nw_src=172.18.0.67,…,actions=ct(commit,table=0,zone=1,nat(src=220.0.0.3,230.0.0.7,240.0.0.123))
>>
>>
>> table=0,ip,nw_src=172.18.0.80,…,actions=ct(commit,table=0,zone=1,nat(src=220.0.0.3,230.0.0.7,240.0.0.123))
>>
>>
>> table=0,ip,nw_src=172.19.0.23,…,actions=ct(commit,table=0,zone=1,nat(src=220.0.0.3,230.0.0.7,240.0.0.123))
>>
>>
>>
>> Ideally, we hope, for different traffic types from the same internal IP
>> (say 172.18.0.67), some can SNAT to 220.0.0.3, some can SNAT to 230.0.0.7,
>> some can SNAT to
>>
>> 240.0.0.123, that way, they can leverage total bandwidth of several BGP
>> lines.
>>
>>
>>
>> I know current OVS can’t support the above IP list for snat, but it is
>> indeed required in reality, I don’t understand why OVS can’t do in this
>> way, is it linux conntrack limitation or what else reason? I think it is
>> similar to IP range which can be supported.
>>
>
> Presently, the limitation is both at the Openflow layer and implementation
> details at datapath
> The layer above (a controller or even a script) can do the mapping taking
> into account the desired distribution
> A controller can/will often do this and similar types of configuration
> specification.
>

btw, in terms of controller config support, Openflow Groups with select
type may help here


>
>
>>
>>
>>
>> *发件人:* Darrell Ball [mailto:dlu998 at gmail.com]
>> *发送时间:* 2019年11月6日 9:38
>> *收件人:* Yi Yang (杨燚)-云服务集团 <yangyi01 at inspur.com>
>> *抄送:* ovs-discuss at openvswitch.org; ovs-dev at openvswitch.org
>> *主题:* Re: [ovs-dev] can OVS conntrack support IP list like this:
>> actions=ct(commit, table=0, zone=1, nat(dst=220.0.0.3, 220.0.0.7,
>> 220.0.0.123))?
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Nov 5, 2019 at 4:32 PM Yi Yang (杨燚)-云服务集团 <yangyi01 at inspur.com>
>> wrote:
>>
>> Hi, folks
>>
>>
>>
>> We need to do SNAT for many internal IPs by just using several public IPs,
>> we also need to do DNAT by some other public IPs for exposing webservice,
>> openflow rules look like the below:
>>
>>
>>
>> table=0,ip,nw_src=172.17.0.0/16,
>> …,actions=ct(commit,table=0,zone=1,nat(src=
>> 220.0.0.3,220.0.0.7,220.0.0.123))
>>
>>
>> table=0,ip,nw_src=172.18.0.67,…,actions=ct(commit,table=0,zone=1,nat(src=22
>> 0.0.0.3,220.0.0.7,220.0.0.123))
>>
>>
>>
>> for snat, you can map some subset of private IPs to a given public IP and
>> so on
>>
>>
>>
>>
>>
>>
>> table=0,ip,tcp,nw_dst=220.0.0.11,tp_dst=80,…,actions=ct(commit,table=0,zone
>> =2,nat(dst=172.16.0.100:80))
>>
>> table=0,ip,tcp,nw_dst=220.0.0.11,
>> tp_dst=443,…,actions=ct(commit,table=0,zone=2,nat(dst=172.16.0.100:443))
>>
>>
>>
>> you are mapping 'to' private IPs, so you have control over the range
>>
>>
>>
>>
>>
>>
>>
>>
>> From ct document, it seems it can’t support IP list for nat, anybody knows
>> how we can handle such cases in some kind feasible way?
>>
>>
>>
>> In addition, is it ok if multiple openflow rules use the same NAT IP:PORT
>> combination? I’m not sure if it will result in some conflicts for SNAT,
>> because all of them need to do dynamic source port mapping, per my test,
>> it
>> seems this isn’t a problem.
>>
>>
>>
>> IIUC, as long as tuples are unique, it should be fine
>>
>>
>>
>>
>>
>>
>> Thank you all in advance and appreciate your help sincerely.
>>
>> _______________________________________________
>> dev mailing list
>> dev at openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20191107/b0e5337e/attachment.html>


More information about the discuss mailing list