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 Thu, Nov 7, 2019 at 8:05 AM Darrell Ball wrote: > > > On Wed, Nov 6, 2019 at 5:01 PM Yi Yang (杨燚)-云服务集团 > 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:dlu...@gmail.com] >> *发送时间:* 2019年11月6日 9:38 >> *收件人:* Yi Yang (杨燚)-云服务集团 >> *抄送:* ovs-disc...@openvswitch.org; ovs-dev@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 (杨燚)-云服务集团 >> 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 >> d...@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> >> ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
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 Wed, Nov 6, 2019 at 5:01 PM Yi Yang (杨燚)-云服务集团 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. > > > > *发件人:* Darrell Ball [mailto:dlu...@gmail.com] > *发送时间:* 2019年11月6日 9:38 > *收件人:* Yi Yang (杨燚)-云服务集团 > *抄送:* ovs-disc...@openvswitch.org; ovs-dev@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 (杨燚)-云服务集团 > 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 > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
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 5:37 PM Darrell Ball wrote: > > > On Tue, Nov 5, 2019 at 4:32 PM Yi Yang (杨燚)-云服务集团 > 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 > 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 > > >> >> >> >> Thank you all in advance and appreciate your help sincerely. >> >> ___ >> dev mailing list >> d...@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
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 (杨燚)-云服务集团 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 > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
