Re: small issue with mpe

On Wed, May 24, 2023 at 01:31:56PM +1000, David Gwynne wrote:
>
>
> > On 23 May 2023, at 17:40, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
> >
> > On Tue, May 23, 2023 at 07:09:51AM -0000, Stuart Henderson wrote:
> >> On 2023-05-23, David Gwynne <david@gwynne.id.au> wrote:
> >>> On Sat, May 20, 2023 at 09:44:51AM +0200, Holger Glaess wrote:
> >>>> hi
> >>>>
> >>>>
> >>>> looks like that the patch works , but should not print "tunneldomain"
> >>>> instead of "rdomain" ?
> >>>
> >>> that's an interesting question.
> >>>
> >>> ifconfig does not aim to produce output that can then be used as input
> >>> for ifconfig again. printing it as rdomain is at least consistent with
> >>> how it's printed on the tunnel: line for things like etherip and gif,
> >>> and i guess the assumption is you can figure out that it's tunneldomain
> >>> from the context.
> >>
> >> things are a bit inconsistent here - doesn't this actually take an rtable
> >> not an rdomain? (wg uses and prints "wgrtable" for what I think is the
> >> equivalent thing).
> >
> > I think this is a general issue with tunneldomain. It should be
> > tunneltable since it used for two things. The route lookup of the tunnel
> > endpoints and to alter the mbufs rdomain on encapsulation / decapsulation.
> > At least in theory this is how it should work but someone needs to verify
> > that all drivers really behave like this.
>
> ifconfig drv0 rdomain specifies which rdomain and send packets into the
> interface, and which rdomain the packets coming out of the interface
> will use. this is the same on all interfaces whether they're tunnels or
> not.
>
> ifconfig drv0 tunneldomain specifies the rdomain that the encapsulated
> packets operate in.
>
> rdomain and tunneldomain (if supported) are always in effect and in the
> same way. packets sent from an rdomain out a tunnel will get the tunnel
> headers added to the packet and the rdomain rewritten to the
> tunneldomain value (which could be 0). encapsulated packets from the
> remote tunnel endpoint have to match the tunneldomain before the tunnel
> interface will match them and decapsulate them, and once they're
> decapsulated the rdomain on the packet is set to the interface rdomain
> value.

I agree with all you wrote. There is one part were the tunneldomain could
be considered an rtableid (and not a pure rdomainid).
When sending out encapsulated packets a route lookup is done using the
tunneldomain value. For this lookup it would make sense to allow an
rtableid. This only affects sending out traffic, on the receive side the
system needs to lookup the endpoint using the rdomain using rtable_l2()
(this is similar on how setrtable(2) and the corresponding getsockopt()
work on sockets).

Now there was never a feature request to send out gre/gif traffic using an
alternate routing table and so I think we can keep this the way it is.

--
:wq Claudio