netdev - Re: [PATCH net-next 0/3] net/sched: iptunnel encap/decap/classify using TC

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20160823090557.GA10223@office.localdomain>
Date:   Tue, 23 Aug 2016 12:05:57 +0300
From:   Amir Vadai <amir@...ai.me>
To:     Tom Herbert <tom@...bertland.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        John Fastabend <john.r.fastabend@...el.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        Hadar Har-Zion <hadarh@...lanox.com>
Subject: Re: [PATCH net-next 0/3] net/sched: iptunnel encap/decap/classify
 using TC

On Mon, Aug 22, 2016 at 03:23:45PM -0700, Tom Herbert wrote:
> On Mon, Aug 22, 2016 at 7:38 AM, Amir Vadai <amir@...ai.me> wrote:
> > Hi,
> >
> > This patchset introduces iptunnel support using the TC subsystem.
> >
> > In the decap flow, it enables the user to redirect packets from a shared tunnel
> > device and classify by outer and inner headers. The outer headers are extracted
> > from the metadata and used by the flower filter. A new action act_iptunnel,
> > releases the metadata.
> >
> > In the encap flow, act_iptunnel creates a metadata object to be used by the
> > shared tunnel device. The actual redirection to the tunnel device is done using
> > act_mirred.
> >
> > For example:
> > $ tc qdisc add dev vnet0 ingress
> > $ tc filter add dev vnet0 protocol ip parent ffff: \
> >     flower \
> >           ip_proto 1 \
> >         action iptunnel encap \
> >           src_ip 11.11.0.1 \
> >                 dst_ip 11.11.0.2 \
> >                 id 11 \
> >         action mirred egress redirect dev vxlan0
> >
> Is the device required to be a tunnel device? Consider that with LWT
> we can perform this sort of encapsulation without requiring a special
> device...
> 
> Tom
> 
Yes and no. This action is relevant only for a shared tunnel device.
like the one you get with:
$ ip link add vxlan0 type vxlan dstport 4789 external
A user can add metadata using this action and redirect to any netdev,
but only the shared tunnel netdev will do something with it.

Regarding LWT, in our use case we need to have classification in
addition to the routing, have both encap and decap operations and be
ready to add offloading to the API. For that, TC subsystem looked
the most suiteable.

Thanks,
Amir

[...]