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
[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))?
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)) 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)) >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. Thank you all in advance and appreciate your help sincerely. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
