@Bence, thank you for confirming the problem.

and we also did some debugging work, we found so far:

1, There seems to be no problem with the flow, because 'ovs-dpctl dump-flows' on stein and ussuri are the same when ping vm from sg-xxx

# ussuri
recirc_id(0),in_port(13),ct_state(-trk),eth(src=fa:16:3e:d3:6f:80),eth_type(0x0800),ipv4(src=192.168.21.151,proto=6,frag=no), packets:24, bytes:2560, used:0.396s, flags:SP., actions:ct(zone=3),recirc(0x4b)

＃stein
recirc_id(0),in_port(12),ct_state(-trk),eth(src=fa:16:3e:4c:29:6d),eth_type(0x0800),ipv4(src=192.168.21.5,proto=6,frag=no), packets:3271, bytes:307846, used:1.656s, flags:SP., actions:ct(zone=3),recirc(0x1)

and we also reviewed the flow in the whole path: vm -> qrouter-xxx -> br-int -> br-tun -> vxlan-xxx, pls see - https://pastebin.ubuntu.com/p/vzNjb3JT5W/

2, There seems to be no problem with conntrack, because 'conntrack -L | grep mark=1 |grep 192.168.21' is empty when ping vm from sg-xxx

3, There seems to be no problem with the route

# ip netns exec qrouter-7a918e87-1cc8-4252-87d1-e84b4c12c616 ip rule list |grep 192
3232240897:     from 192.168.21.1/24 lookup 3232240897
# ip netns exec qrouter-7a918e87-1cc8-4252-87d1-e84b4c12c616 ip route list table 3232240897
default via 192.168.21.168 dev qr-218eed51-82 proto static 

4, There seem to be some differences in firewall rules on stein and ussuri, ussuri has table 94

ovs-appctl ofproto/trace br-int 'in_port=9,ip,nw_proto=1,nw_src=192.168.21.151,nw_dst=192.168.21.168,dl_src=fa:16:3e:d3:6f:80,dl_dst=fa:16:3e:34:9e:64' --ct-next 'trk,est'

ussuri - https://pastebin.ubuntu.com/p/tSQXQFfPBw/
stein - https://pastebin.ubuntu.com/p/ZTfXd6rVZ9/

ussuri has the following flow rule so that it didn't go through br-tun

94. reg6=0x3,dl_dst=fa:16:3e:34:9e:64, priority 12, cookie 0x8a4738b01717a42e
    output:8

so then we get the following flow rule for sg-xxx interface on compute node.

root@juju-21f0ba-focal-10:/home/ubuntu# ovs-ofctl dump-flows br-int | grep fa:16:3e:34:9e:64
 cookie=0x8a4738b01717a42e, duration=13204.575s, table=1, n_packets=0, n_bytes=0, idle_age=65534, priority=20,dl_vlan=3,dl_dst=fa:16:3e:34:9e:64 actions=mod_dl_src:fa:16:3e:5e:d6:96,resubmit(,60)
 cookie=0x8a4738b01717a42e, duration=13204.573s, table=60, n_packets=0, n_bytes=0, idle_age=65534, priority=20,dl_vlan=3,dl_dst=fa:16:3e:34:9e:64 actions=strip_vlan,output:8
 cookie=0x8a4738b01717a42e, duration=13202.646s, table=94, n_packets=12485, n_bytes=1063359, idle_age=0, priority=12,reg6=0x3,dl_dst=fa:16:3e:34:9e:64 actions=output:8
 cookie=0x8a4738b01717a42e, duration=13202.646s, table=94, n_packets=0, n_bytes=0, idle_age=65534, priority=10,reg6=0x3,dl_src=fa:16:3e:34:9e:64,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:3,output:2

root@juju-824e75-train2-8:~# ovs-ofctl dump-flows br-int | grep fa:16:3e:6b:60:7d
 cookie=0x4580a22bf3824b00, duration=13818.613s, table=1, n_packets=0, n_bytes=0, idle_age=65534, priority=20,dl_vlan=3,dl_dst=fa:16:3e:6b:60:7d actions=mod_dl_src:fa:16:3e:4b:f5:19,resubmit(,60)
 cookie=0x4580a22bf3824b00, duration=13818.611s, table=60, n_packets=0, n_bytes=0, idle_age=65534, priority=20,dl_vlan=3,dl_dst=fa:16:3e:6b:60:7d actions=strip_vlan,output:7

5, so now it seems table=94 is the key, 94 is ACCEPTED_EGRESS_TRAFFIC_NORMAL_TABLE, it's realted to firewall, so I doubt the following commits

$ git log --oneline 1c2e10f859...16.0.0 neutron/agent/linux/openvswitch_firewall/firewall.py
6dbba8d5ce Check SG members instead of ports to skip flow update
efa8dd0895 Add accepted egress direct flow
991126eb6e Merge "[OVS FW] Clean port rules if port not found in ovsdb"
b01e0c2aa9 [OVS FW] Clean port rules if port not found in ovsdb
5cb0ff418a Add more condition to check sg member exist
a94cb83e18 Merge "Handle OVSFWPortNotFound and OVSFWTagNotFound in ovs firewall"
e801159003 Handle OVSFWPortNotFound and OVSFWTagNotFound in ovs firewall
4b67a06403 Log OVS firewall conjunction creation

and I have tried efa8dd0895, set explicitly_egress_direct=false, but the problem still exists.