See reply at the bottom. On Thu, Nov 3, 2016 at 6:06 PM, Guru Shetty <guru....@gmail.com> wrote:
<snip> > It seems to me that the root of the problem has to do with > > three issues: > > 1. SNAT (and DNAT) rules should not apply to ct.rpl traffic, > > instead only UNSNAT (and UNDNAT) rules should apply. > > Conntrack can tell which traffic is reply traffic, but this would > > require going through conntrack with recirc prior to SNAT. > > Correct > > <snip> > > > And to do that in the pipeline, we check whether a packet > >> has already been SNATted and if it has a transformation, we should not > >> do it again. > > > > I think this is a roundabout way of implementing 1 above. If all > > gateway router traffic is subject to SNAT, then reply traffic will > > always hit UNSNAT and so avoid the SNAT stage. > > Right. > > > > > The question is whether a solution that requires all traffic to > > be subject to SNAT is acceptable, for deployment scenarios > > where SNAT rules have coarse enough IP address prefixes > > to catch traffic in both directions? > > I did not understand the above point. Can you elaborate a bit. > This approach imposes symmetry in terms of which traffic is subject to SNAT, when an SNAT rule is coarse enough to match source IP addresses in both directions, for example 0.0.0.0/0. If you wanted SNAT imposed for 0.0.0.0/0 in the inward direction, then you will have SNAT imposed for 0.0.0.0/0 in the outward direction, with no exceptions except for SNAT longest match overrides. I guess that is why you suggested the 'nosnat' second patch? Mickey > > > > Mickey > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > http://openvswitch.org/mailman/listinfo/dev > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
