On 16-08-15 05:59 AM, Amir Vadai wrote: > On Mon, Aug 15, 2016 at 02:34:00PM +0200, Jiri Pirko wrote: >> Mon, Aug 15, 2016 at 12:08:10PM CEST, j...@mojatatu.com wrote: >>> On 16-08-15 05:08 AM, Amir Vadai wrote: >>>> On Mon, Aug 15, 2016 at 11:17:40AM +0300, Amir Vadai wrote: >>>>> On Mon, Aug 15, 2016 at 09:11:22AM +0200, Jiri Pirko wrote: >>>>>> Sun, Aug 14, 2016 at 07:53:30PM CEST, xiyou.wangc...@gmail.com wrote: >>> >>>>> >>>>> 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 >> >> >>> >>> 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 >>> >>>> >>>> # 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
