[ovs-dev] [RFC PATCH 5/5] openvswitch: Interface with NAT.
fw at strlen.de
Wed Oct 21 14:42:12 UTC 2015
Thomas Graf <tgraf at suug.ch> wrote:
> On 10/21/15 at 11:34am, Florian Westphal wrote:
> > Jarno Rajahalme <jrajahalme at 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
- 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 ;)
More information about the dev