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? > >i.e there is no redirect needed here, no? > >cheers, >jamal
