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:

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

i.e there is no redirect needed here, no?

cheers,
jamal

Reply via email to