Re: [PATCH net 0/2] lwtunnel: make it really work, for IPv4

[Thomas Graf <tgraf@suug.ch>]

On 09/22/15 at 06:12pm, Jiri Benc wrote:
> One of the selling points of lwtunnel was the ability to specify the tunnel
> destination using routes. However, this doesn't really work currently, as
> ARP and ndisc replies are not handled correctly. ARP and ndisc replies won't
> have tunnel metadata attached, thus they will be sent out with the default
> parameters or not sent at all, either way never reaching the requester.

Note that ARP is not strictly required in most cases where this form of
encapsulation is used. In particular any kind of broadcasting is very
undesirable for obvious reasons ;-)

The matrix which maps overlay addresses to tunnel endpoint and tunnel id
would normally also contain the MAC address of the virtual endpoint or a
dummy MAC if it's a L3 only endpoint (which is what you want to go for
these days) so you would typically answer the ARP requests locally or just
fill the neighbour cache yourself.

However, I very much agree that we should make this work since it eases
use.

> Most of the egress tunnel parameters can be inferred from the ingress
> metada. The only and important exception is UDP ports. This patchset infers
> the egress data from the ingress data and disallow settings of UDP ports in
> tunnel routes. If there's a need for different UDP ports, a new interface
> needs to be created for each port combination. Note that it's still possible
> to specify the UDP ports to use, it just needs to be done while creating the
> vxlan/geneve interface.

I would assume that dst.tp_dst = src.tp_dst would work well in practice.
The port number should be standardized anyway and would only differ to
support non compatible flavours of VXLAN.

I don't mind putting this restriction on though.