> On Nov 3, 2016, at 7:16 PM, Mickey Spiegel <mickeys....@gmail.com> wrote: > > 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?
Thanks for the explanation. You are right about the situation. Do you have any design suggestions to solve this overall problem in a easy way? > > 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
