netdev - Re: VLAN retagging for packets switched between 2 certain ports

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+h21hpWknrGjyK0eRVFmx7a1WWRyCZJtFRgGzr3YyeL3y2gYw@mail.gmail.com>
Date:   Thu, 6 Feb 2020 11:32:52 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     netdev <netdev@...r.kernel.org>
Subject: Re: VLAN retagging for packets switched between 2 certain ports

On Thu, 6 Feb 2020 at 11:02, Vladimir Oltean <olteanv@...il.com> wrote:
>
> Hi netdev,
>
> I am interested in modeling the following classifier/action with tc filters:
> - Match packets with VID N received on port A and going towards port B
> - Replace VID with M
>
> Some hardware (DSA switch) I am working on supports this, so it would
> be good if I could model this with tc in a way that can be offloaded.
> In man tc-flower I found the following matches:
>        indev ifname
>               Match on incoming interface name. Obviously this makes
> sense only for forwarded flows.  ifname is the name of an interface
> which must exist at the time of tc invocation.
>        vlan_id VID
>               Match on vlan tag id.  VID is an unsigned 12bit value in
> decimal format.
>
> And there is a generic "vlan" action (man tc-vlan) that supports the
> "modify" command.
>
> Judging from this syntax, I would need to add a tc-flower rule on the
> egress qdisc of swpB, with indev swpA and vlan_id N.
> But what should I do if I need to do VLAN retagging towards the CPU
> (where DSA does not give me a hook for attaching tc filters)?
>
> Thanks,
> -Vladimir

While I don't want to influence the advice that I get, I tried to see
this from the perspective of "what would a non-DSA device do?".
So what I think would work for me is:
- For VLAN retagging of autonomously forwarded flows (between 2
front-panel ports) I can do the egress filter with indev that I
mentioned above.
- For VLAN retagging towards the CPU, I can just attach the filter to
the ingress qdisc and not specify an indev at all. The idea being that
this filter will match on locally terminated packets and not on all
packets received on this port.
Would this be confusing?

-Vladimir