Re: [RFC net-next 0/2] net/sched: cls_flower, act_mirred: VXLAN redirect using TC

On 16-08-15 05:59 AM, Amir Vadai wrote:

On Mon, Aug 15, 2016 at 02:34:00PM +0200, Jiri Pirko wrote:

quoted

Mon, Aug 15, 2016 at 12:08:10PM CEST, jhs@mojatatu.com wrote:

quoted

On 16-08-15 05:08 AM, Amir Vadai wrote:

quoted

On Mon, Aug 15, 2016 at 11:17:40AM +0300, Amir Vadai wrote:

quoted

On Mon, Aug 15, 2016 at 09:11:22AM +0200, Jiri Pirko wrote:

quoted

Sun, Aug 14, 2016 at 07:53:30PM CEST, xiyou.wangcong@gmail.com wrote:

quoted

quoted

Thanks,
Amir

Any objection to the following?

# ENCAP rule
tc filter add dev $ETH protocol ip parent ffff: prio 10 \
		flower ip_proto 1 \
		action set_tunnel_key src_ip 11.11.0.1 dst_ip 11.11.0.2 key_id 11 dst_port 4789 \
		action mirred egress redirect dev $VXLAN

Assuming $VXLAN is actually not a linux netdev of type vxlan?
then the action does vxlan encap redirect sends it to the $VXLAN
dev with encapsulation in place.
Sounds to me like a name like "vxlan" would be more usable. Example:

I believe those are generic tunelling data

quoted

tc filter add dev $ETH protocol ip parent ffff: prio 10 ..
action vxlan encap src_ip 11.11.0.1 dst_ip 11.11.0.2 key_id 11 ....
action mirred egress redirect dev eth0

quoted

# DECAP rule
tc filter add dev $VXLAN protocol ip parent ffff: prio 10 \
		flower \
			enc_src_ip 11.11.0.2 enc_dst_ip 11.11.0.1 enc_key_id 11 \
			ip_proto 1 \
		action mirred egress redirect dev $ETH

And a decap would be of the form:
tc filter add dev $ETH protocol ip parent ffff: prio 10 ..
action vxlan decap

That's right. Amir, don't you need decap here to drop the tunnel
metadata?

Right. will add a decap that will release it.

FWIW this new approach looks good to me.


Thanks,
John