description:

topology:
Server (External to OVN)

Public Switch

Gateway Router

Internal Switch

Client

Configuration details:

The Gateway Router has an SNAT rule that changes the Client IP address to the Gateway Router's "public" IP address.
The Gateway Router has configured the gateway_mtu on the port connected to the Internal Switch

the client send a big packet to server, when server send icmp reply to router, as the packet is too big, router would send a "needs fragmentation" to server, but there is something wrong with the addr for this packet, so packet would be ignored by server, so that server won't send right packet back to client.

version:
ovn23.03-23.03.1-39.el9fdp.x86_64

reproducer:
systemctl start openvswitch
systemctl start ovn-northd
ovn-nbctl set-connection ptcp:6641
ovn-sbctl set-connection ptcp:6642
ovs-vsctl set open . external_ids:system-id=hv1 external_ids:ovn-remote=tcp:127.0.0.1:6642 external_ids:ovn-encap-type=geneve external_ids:ovn-encap-ip=127.0.0.1
systemctl restart ovn-controller

ovs-vsctl add-br br-ext
ovs-vsctl set Open_vSwitch . external-ids:ovn-bridge-mappings=phynet:br-ext

ovn-nbctl lr-add lr
ovn-nbctl ls-add internal
ovn-nbctl ls-add public

ovn-nbctl lrp-add lr lr-pub 00:00:01:01:02:03 192.168.1.1/24
ovn-nbctl lsp-add public pub-lr – set Logical_Switch_Port pub-lr \
type=router options:router-port=lr-pub addresses=\"00:00:01:01:02:03\"

ovn-nbctl lrp-add lr lr-internal 00:00:01:01:02:04 172.16.1.1/24
ovn-nbctl lsp-add internal internal-lr – set Logical_Switch_Port internal-lr \
type=router options:router-port=lr-internal addresses=\"00:00:01:01:02:04\"

ovn-nbctl lsp-add public ln_port \
– lsp-set-addresses ln_port unknown \
– lsp-set-type ln_port localnet \
– lsp-set-options ln_port network_name=phynet

ovn-nbctl lsp-add internal client \
– lsp-set-addresses client "f0:00:0f:01:02:03 172.16.1.2"
ovn-nbctl set logical_router lr options:chassis=hv1
ovn-nbctl set logical_router_port lr-internal options:gateway_mtu=800

ovs-vsctl add-port br-int client – set interface client type=internal external_ids:iface-id=client
ip netns add client
ip link set client netns client
ip netns exec client ip link set client address f0:00:0f:01:02:03
ip netns exec client ip addr add 172.16.1.2/24 dev client
ip netns exec client ip link set client up
ip netns exec client ip route add default via 172.16.1.1

ovs-vsctl add-port br-ext server – set interface server type=internal
ip netns add server
ip link set server netns server
ip netns exec server ip link set server up
ip netns exec server ip addr add 192.168.1.2/24 dev server

ovn-nbctl lr-nat-add lr snat 192.168.1.1 172.16.1.2
ip netns exec client ping 192.168.1.2 -c 1
ip netns exec client ping 192.168.1.2 -c 1 -s 1400
ip netns exec client ping 192.168.1.2 -c 1 -s 1400 -W 2
ip netns exec client ping 192.168.1.2 -c 1 -s 1400 -W 2

expected result:

the last ping should pass

actual result:

the last ping failed, and following is the packet capture on server:

21:19:20.270332 5a:c8:5e:04:ca:8c > 00:00:01:01:02:03, ethertype IPv4 (0x0800), length 1442: (tos 0x0, ttl 64, id 1625, offset 0, flags [none], proto ICMP (1), length 1428)
192.168.1.2 > 192.168.1.1: ICMP echo reply, id 44557, seq 1, length 1408
21:19:20.271145 00:00:01:01:02:03 > 5a:c8:5e:04:ca:8c, ethertype IPv4 (0x0800), length 576: (tos 0x0, ttl 254, id 0, offset 0, flags [DF], proto ICMP (1), length 562)
172.16.1.1 > 192.168.1.2: ICMP 172.16.1.2 unreachable - need to frag (mtu 800), length 542
(tos 0x0, ttl 63, id 1625, offset 0, flags [none], proto ICMP (1), length 1428)
192.168.1.2 > 172.16.1.2: ICMP echo reply, id 44557, seq 1, length 1408

other information:

[root@kvm-05-guest01 jira39]# rpm -qa | grep -E "openvswitch3.1|ovn23.03"
ovn23.03-23.03.1-39.el9fdp.x86_64
ovn23.03-central-23.03.1-39.el9fdp.x86_64
ovn23.03-host-23.03.1-39.el9fdp.x86_64
openvswitch3.1-3.1.0-65.el9fdp.x86_64

this issue is related to https://issues.redhat.com/browse/FDP-39, FDP-39 solve the issue when add snat "ovn-nbctl lr-nat-add lr snat 192.168.1.1 172.16.1.2/24", but when add snat with "ovn-nbctl lr-nat-add lr snat 192.168.1.1 172.16.1.2", the issue still exist, so open this ticket to track the remaining issue.