Hi: Almost missed the conversation
> The approach in Linux 4.3 seems to be that in addition to both original > and reply direction tuples (i.e., address/port pairs) being in the > specified zone, only one of them can be in that zone, in which case the > other tuple is always considered to be in zone 0. One way to expose this > via the OVS API would be to add src_zone and dst_zone attributes to the CT > action as (exclusive) alternatives to the existing zone attribute. Using > one of the alternatives would imply that the tuple for the other direction > would be in the zone 0. > > I doubt the kernel approach is suitable for ovs, because the kernal lack the support to pass packets from one zone to another zone, the solution looks fine. it still need to lookup ct table twice, once for each zone. And the only optimize is omit the SNAT in the tenant zone, but the ct entry is created as long as the kernel module is loaded. I haven't tested it, but I don't expect much performance improve. In the contract, in ovs datapath, we can route packets from one zone to another zone directly, which may omit a ct table lookup, and a potential upcall. The new variable `zone-orig` may help for implement cross zone nat in ovs. in my origin design, two zone id column is needed in the table, one for src and one for dst. Limited to only one zone id in the table, direction must be provided before lookup the table. e.g. SNAT zone:tenent => zone:public nat(zone_orig=t,zone=public,masq=x.x.x.x) reverse path: nat(reverse,zone=public) following rules can match zone_orig The solution isn't perfect, but is realistic. In some extreme scenario, it may not work. But in additional we must make sure floating ip works, which is DNAT from gateway/public zone to tenant zone. The patch didn't explain how DNAT works, I don't know if addition works are needed. after all, I'm glad to see there is progress in the direction. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
