Hello David, I tried and it seems i can reproduce it:
# Create test NS root@host:~# ip netns add testns # Create veth pair, veth0 in host, veth1 in NS root@host:~# ip link add veth0 type veth peer name veth1 root@host:~# ip link set veth1 netns testns # Configure veth1 (NS) root@host:~# ip netns exec testns ip addr add 192.168.252.209/24 dev veth1 root@host:~# ip netns exec testns ip link set dev veth1 up root@host:~# ip netns exec testns ip route add default via 192.168.252.100 root@host:~# ip netns exec testns ip route add 192.168.249.0/24 nexthop via 192.168.252.250 nexthop via 192.168.252.252 # Configure veth0 (host) root@host:~# brctl addif vmbr2 veth0 root@host:~# ip link set veth0 up # Tests root@host:~# ip netns exec testns ping -M do -s 1450 192.168.249.116 PING 192.168.249.116 (192.168.249.116) 1450(1478) bytes of data. >From 192.168.252.252 icmp_seq=1 Frag needed and DF set (mtu = 1366) ping: local error: Message too long, mtu=1366 ping: local error: Message too long, mtu=1366 ping: local error: Message too long, mtu=1366 ^C --- 192.168.249.116 ping statistics --- 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 81ms root@host:~# ip netns exec testns ping -M do -s 1450 192.168.249.134 PING 192.168.249.134 (192.168.249.134) 1450(1478) bytes of data. >From 192.168.252.252 icmp_seq=1 Frag needed and DF set (mtu = 1366) >From 192.168.252.252 icmp_seq=2 Frag needed and DF set (mtu = 1366) >From 192.168.252.252 icmp_seq=3 Frag needed and DF set (mtu = 1366) ^C --- 192.168.249.134 ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 40ms root@host:~# ip netns exec testns ip route show cache 192.168.249.116 via 192.168.252.250 dev veth1 cache expires 584sec mtu 1366 192.168.249.134 via 192.168.252.250 dev veth1 cache expires 593sec mtu 1366 root@host:~# ip netns exec testns ip route get 192.168.249.116 192.168.249.116 via 192.168.252.250 dev veth1 src 192.168.252.209 uid 0 cache expires 578sec mtu 1366 root@host:~# ip netns exec testns ip route get 192.168.249.134 192.168.249.134 via 192.168.252.252 dev veth1 src 192.168.252.209 uid 0 cache Please notice the above, 'ip route show cache' and 'ip route get' return different nexthop for 192.168.249.134, i suspect that may be part of the problem. Thank you, Kfir On Tue, Aug 11, 2020 at 1:13 AM David Ahern <dsah...@gmail.com> wrote: > > On 8/3/20 12:39 PM, mastertheknife wrote: > > In summary: It seems that it doesn't matter who is the nexthop. If the > > ICMP response isn't from the nexthop, it'll be rejected. > > About why i couldn't reproduce this outside LXC, i don't know yet but > > i will keep trying to figure this out. > > do you have a shell script that reproduces the problem?