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