Thomas Graf <tg...@suug.ch> wrote: > On 10/21/15 at 11:34am, Florian Westphal wrote: > > Jarno Rajahalme <jrajaha...@nicira.com> wrote: > > > #define OVS_CS_F_REPLY_DIR 0x08 /* Flow is in the reply > > > direction. */ > > > #define OVS_CS_F_INVALID 0x10 /* Could not track connection. */ > > > #define OVS_CS_F_TRACKED 0x20 /* Conntrack has occurred. */ > > > +#define OVS_CS_F_SRC_NAT 0x40 /* Packet's source address/port > > > was > > > + mangled by NAT. */ > > > +#define OVS_CS_F_DST_NAT 0x80 /* Packet's destination > > > address/port > > > + was mangled by NAT. */ > > > > I'm blind -- how does ovs deal with change of output device and the > > ether dst mac as result of a l3 dst translation? > > I assume you are referring to rewriting of L2 and the forwarding decision > after NAT. As NAT is performed in combination with conntrack, the packet > is recirculated and hits the flow table again after NAT. That 2nd > stage flow must take are of performing L3 by rewriting L2, decrementing > TTL, etc.
> Is this what you are referring to? Yes, exactly, thanks for answering my question. [ in classic bridge netfilter this requires route lookup & neigh stunts to deal with the consequences of dnat, i.e. - route says dst is reachable via some other interface not part of bridge - route says that dst is localhost - route says its on same bridge, but neigh has no idea what the new dst mac address is,etc. I was kinda disappointed to not see similar tur^W hacks ;) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html