On 11/19/2019 5:59 AM, Pablo Neira Ayuso wrote:
> On Sat, Nov 16, 2019 at 04:06:02PM +0800, wenxu wrote:
>> 在 2019/11/16 5:48, Pablo Neira Ayuso 写道:
>>> On Fri, Nov 15, 2019 at 08:03:26PM +0800, wenxu@xxxxxxxxx wrote:
>>>> From: wenxu <wenxu@xxxxxxxxx>
>>>>
>>>> This patch provide tunnel offload based on route lwtunnel.
>>>> The first two patches support indr callback setup
>>>> Then add tunnel match and action offload
>>> Could you provide a configuration script for this tunnel setup?
>>>
>>> Thanks.
>> The following is a simple configure for tunnel offload forward
>>
>>
>> ip link add dev gre_sys type gretap key 1000
>>
>> ip link add user1 type vrf table 1
>>
>> ip l set dev gre1000 master user1
>>
>> ip l set dev vf master user1
>>
>> ip r a 10.0.0.7 dev vf table 1
>> ip r a default via 10.0.0.100 encap ip id 1000 dst 172.168.0.7 key dev gre1000 table 1 onlink
>>
>> nft add flowtable firewall fb1 { hook ingress priority 0 \; flags offload \; devices = { gre1000, vf } \; }
> Thanks for describing, but how does this work in software?
>
> I'd appreciate if you can describe a configuration in software (no
> offload) that I can use here for testing, including how you're
> generating traffic there for testing.
There is the whole test script for software only. flowtable offload is
already can work with vrf.
ip netns add ns1
ip netns add cl
ip l add dev veth1 type veth peer name eth0 netns ns1
ip l add dev vethc type veth peer name eth0 netns cl
ip netns exec ns1 ifconfig eth0 10.0.0.7/24 up
ip netns exec ns1 ip r add default via 10.0.0.1
ifconfig vethc 172.168.0.7/24 up
ip l add dev tun1 type gretap external
ip netns exec cl ifconfig eth0 172.168.0.17/24 up
ip netns exec cl ip l add dev tun type gretap local 172.168.0.17 remote 172.168.0.7 key 1000
ip netns exec cl ifconfig tun 10.0.1.7/24 up
ip netns exec cl ip r add default via 10.0.1.1
ip link add user1 type vrf table 1
ip l set user1 up
ip l set dev tun1 master user1
ifconfig veth1 down
ip l set dev veth1 master user1
ifconfig veth1 10.0.0.1/24 up
ifconfig tun1 10.0.1.1/24 up
ip r r 10.0.0.7 dev veth1 table 1
ip r r 10.0.1.7 encap ip id 1000 dst 172.168.0.17 key dev tun1 table 1
nft add table firewall
nft add chain firewall zones { type filter hook prerouting priority - 300 \; }
nft add rule firewall zones counter ct zone set iif map { "tun1" : 1, "veth1" : 1 }
nft add chain firewall rule-1000-ingress
nft add rule firewall rule-1000-ingress ct zone 1 ct state established,related counter accept
nft add rule firewall rule-1000-ingress ct zone 1 ct state invalid counter drop
nft add rule firewall rule-1000-ingress ct zone 1 tcp dport 5001 ct state new counter accept
nft add rule firewall rule-1000-ingress ct zone 1 ip protocol icmp ct state new counter accept
nft add rule firewall rule-1000-ingress counter drop
nft add chain firewall rules-all { type filter hook prerouting priority - 150 \; }
nft add rule firewall rules-all meta iifkind "vrf" counter accept
nft add rule firewall rules-all iif vmap { "tun1" : jump rule-1000-ingress }
nft add flowtable firewall fb1 { hook ingress priority 0 \; devices = { veth1, tun1 } \; }
nft add chain firewall ftb-all {type filter hook forward priority 0 \; policy accept \; }
nft add rule firewall ftb-all ct zone 1 ip protocol tcp flow offload @fb1
you can test it with
ip netns exec ns1 exec iperf -s
ip netns exec ns1 exec iperf -c 10.0.0.7 -t 100 -i 2
cat /proc/net/nf_conntrack | grep zone=1
ipv4 2 tcp 6 src=10.0.1.7 dst=10.0.0.7 sport=56290 dport=5001 src=10.0.0.7 dst=10.0.1.7 sport=5001 dport=56290 [OFFLOAD] mark=0 zone=1 use=3
Ps: there are some tricks. It is better the tun1 as "ip l add dev tun1 type gretap key 1000"
but not " ip l add dev tun1 type gretap external"
But the specific key id gretap when receive the packet will not push up the tun_info which will lead arp response
with no tun_info
I will post a patch to support this in gre.
>
