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  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]
Date:	Mon, 15 Aug 2016 11:17:40 +0300
From:	Amir Vadai <>
To:	Jiri Pirko <>
Cc:	Cong Wang <>,
	John Fastabend <>,
	Jamal Hadi Salim <>,
	Jiri Pirko <>,
	Linux Kernel Network Developers <>,
	Or Gerlitz <>,
	Hadar Har-Zion <>,
	Oded Shanoon <>,
	Amir Vadai <>
Subject: Re: [RFC net-next 0/2] net/sched: cls_flower, act_mirred: VXLAN
 redirect using TC

On Mon, Aug 15, 2016 at 09:11:22AM +0200, Jiri Pirko wrote:
> Sun, Aug 14, 2016 at 07:53:30PM CEST, wrote:
> >On Sun, Aug 14, 2016 at 7:06 AM, Amir Vadai <> wrote:
> >> tc qdisc add dev $ETH ingress
> >>
> >> # ENCAP rule for ARP
> >> tc filter add dev $ETH protocol 0x806 parent ffff: prio 11 \
> >>                 flower \
> >>                 action mirred egress redirect dev $VXLAN enc_src_ip enc_dst_ip enc_key_id 11 enc_dst_port 4789
> >>
> >> # ENCAP rule for ICMP
> >> tc filter add dev $ETH protocol ip parent ffff: prio 10 \
> >>                 flower ip_proto 1 \
> >>                 action mirred egress redirect dev $VXLAN enc_src_ip enc_dst_ip enc_key_id 11 enc_dst_port 4789
> >>
> >
> >I don't like this. This makes mirred action unnecessarily
> >complex, it should really just mirror or redirect packets as
> >it is, why it should be aware of tunnel information?
> >
> >I think you probably need to introduce a new tc action
> >for these tunnel information and pipe it to mirred.
> that is the first thing that I thinked of when I saw the patch. I think
> you can introduce act_vxlan similar to act_vlan.

introducing a new action was the first thing I thought of, but it felt
problematic because the actual encap is done by the redirection to the
vxlan device. This action is only responsible to supply the metadata and
work tightly with the mirred. It is not exactly like vlan that the
push/pop actions can live without mirroring/redirecting.
But still as all of you said, it makes mirred complex with stuff that
shouldn't be there. And between the two options it is better to
introduce a new action.

I will go in this direction.


Powered by blists - more mailing lists