Hi: Problem =======
I'm glad to see that ovs add conntrack support, the conntrack support is great, but I want to push it more forward. Consider this scenario: multiple tenant sharing a single global ip by using nat. ip address in different tenant can be overlapped. let's say tenant A ip x and tenant B ip x want to access internet via nat. Currently we accomplish this by using double-nat tenant A: x:port ---natA--> internal-ip-a:port ---nat--> global-ip:port tenant B: x:port ---natB--> internal-ip-b:port ---nat--> global-ip:port natA and natB is done in their own per tenant namespace, so there is no problem even they have same ip. and second net translate their assigned internal ips to public ip, there internal ips doesn't conflict. Idea ==== Now I want to simplify the process by using a single nat using ovs, I want to translate a ip:port pair from tenant zone to public zone directly: ZoneA:x:port ---nat--> ZonePublic:global-ip:port ZoneB:x:port ---nat--> ZonePublic:global-ip:port Implementation consideration ============================ Currently kernel cf table is not zone/tenant aware, it can only handle ip:port pair. It may extended to handle zone-id. so cf table can be similar to this one zone:s-ip:s-port:d-ip:d-port <------> zone:s-ip:s-port:d-ip:d-port for new connection, src/dst zone is specified by flow: Match: in_port(1),tcp,conn_state=-tracked Action: nat(src_zone=10,dst_zone=20,masq=x.x.x.x) then a new cf entry can be generated like this one: 10:192.168.0.10:4562:8.8.8.8:53 <----> 20:masq-ip:random-port:8.8.8.8:53 The returning packets can be handled by another flow: Match: in_port(2),tcp,conn_state=+established Action: nat(reverse,zone=20) by lookup cf table using 4-tuple plus zone, the cf entry can be easily find, also zone id '10' can be read from cf entry, so ovs know it is translated to zone 10 now. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
