Description of problem: There is a difference when sending IPv4 and IPv6 jumbo UDP packet from a network with bigger MTU to a network with smaller MTU. IPv6 traffic ignores the mtu setting. Additionally, no ICMP 'fragmentation needed' when sending ipv6 packets. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: Note, I reproduced on an environment that had physical networks allowing 9000 bytes MTU but probably can be reproduced on normal environment (with 1500 max physical mtu) by setting lower MTU values on external network (e.g. 1300) 1. Configure external network to use MTU 1500 Result: OVN NB logical_switch entry has external_ids "neutron:mtu"="1500" configured - OK, see [0] below, Logical router port has gateway_mtu set to 1500 - OK Configure external IPv4 subnet and IPv6 subnet 2. Configure internal network to have bigger MTU (8942 in my case) Logical switch port has external_ids "neutron:mtu"="8942" configured - OK, see [0] below. Configure internal IPv4 and IPv6 subnet 3. Launch an instance on the internal network, make sure you are able to ping external IPv4 and IPv6 addresses. Allow ingress UDP traffic on the external host (undercloud in my case) 4. On the instance start tcpdump and send a large UDP packet to external IPv4 address and IPv6 address. Actual results: On IPv4 packet router responds with ICMP 'fragmentation needed' with max allowed size 1482 - OK . Also note, routing table cache is updated to this max mtu. IPv6 packet jumbo packet ignores MTU setting on the neutron external network and just passes. In case packet is not able to pass, no ICMP 'fragmentation needed' message - not OK. See [1], [2] and [3] below. Expected results: Both, IPv4 and IPv6 packets respect neutron:mtu and gateway_mtu settings. ICMP 'fragmentation needed' is sent if packet is bigger than configured external network MTU. Additional info: [0] ovn-nbctl list logical_switch _uuid : 5a86f651-8ea8-4d38-91bd-0f9929bc13e3 acls : [] dns_records : [6bd4698f-5731-41b4-ba2b-50febb91d93a] external_ids : {"neutron:mtu"="1500", "neutron:network_name"=nova, "neutron:qos_policy_id"=null, "neutron:revision_number"="23"} forwarding_groups : [] load_balancer : [] name : neutron-2101e112-98e8-4af3-be4b-8afeb6806ff3 other_config : {mcast_flood_unregistered="false", mcast_snoop="false"} ports : [ae360173-5dd0-4e6d-bab2-f2a2ff7e7be5, b7d598dc-e77b-4dc8-b9d6-96ef120315d7, d7975429-18a9-4a71-bf86-96211c3a93fe, db47cd66-8528-454d-bebb-b048f940ad17] qos_rules : [] _uuid : c729ce96-ee21-46d5-815f-46de5a172cf7 acls : [] dns_records : [4d84d9f1-4d35-418b-9c4a-f081d4c79371] external_ids : {"neutron:mtu"="8942", "neutron:network_name"=internal_A, "neutron:qos_policy_id"=null, "neutron:revision_number"="5"} forwarding_groups : [] load_balancer : [] name : neutron-3907f18e-1c3d-4133-ab20-2ffb4587b7ff other_config : {mcast_flood_unregistered="false", mcast_snoop="false"} ports : [3e088dd4-2819-443b-9e3e-a07e165f035e, 6a8727de-7ee7-49ea-a0f0-0e55fa465623, 88d612e6-94fb-4f48-9e43-666184b0545c, a7d6196d-bed1-47c8-9600-9f40c48d6013, de907261-e605-4da8-ba0d-778db043fdd6] qos_rules : [] [1] ncat console [cloud-user@rhel-int ~]$ nc -4u 10.0.0.66 65000 < 8942_bytes [cloud-user@rhel-int ~]$ nc -6u 2620:52:0:13b8::fe:a5 65000 < 8942_bytes tcpdump console [cloud-user@rhel-int ~]$ sudo tcpdump -Uvvnneei eth0 icmp or icmp6 or port 65000 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes Let's send a IPv4 packet 14:16:58.661244 fa:16:3e:8f:d6:95 > fa:16:3e:19:86:59, ethertype IPv4 (0x0800), length 8234: (tos 0x0, ttl 64, id 19569, offset 0, flags [DF], proto UDP (17), length 8220) 192.168.1.101.53305 > 10.0.0.66.65000: [bad udp cksum 0xec68 -> 0x7d39!] UDP, length 8192 14:16:58.661506 fa:16:3e:8f:d6:95 > fa:16:3e:19:86:59, ethertype IPv4 (0x0800), length 792: (tos 0x0, ttl 64, id 19570, offset 0, flags [DF], proto UDP (17), length 778) 192.168.1.101.53305 > 10.0.0.66.65000: [bad udp cksum 0xcf56 -> 0x3be1!] UDP, length 750 14:16:58.663649 fa:16:3e:19:86:59 > fa:16:3e:8f:d6:95, ethertype IPv4 (0x0800), length 576: (tos 0x0, ttl 254, id 0, offset 0, flags [DF], proto ICMP (1), length 562) 192.168.1.1 > 192.168.1.101: ICMP 10.0.0.66 unreachable - need to frag (mtu 1482), length 542 (tos 0x0, ttl 63, id 19569, offset 0, flags [DF], proto UDP (17), length 8220) 192.168.1.101.53305 > 10.0.0.66.65000: UDP, length 8192 14:16:58.664000 fa:16:3e:19:86:59 > fa:16:3e:8f:d6:95, ethertype IPv4 (0x0800), length 590: (tos 0xc0, ttl 63, id 32135, offset 0, flags [none], proto ICMP (1), length 576) 10.0.0.66 > 192.168.1.101: ICMP 10.0.0.66 udp port 65000 unreachable, length 556 (tos 0x0, ttl 63, id 19570, offset 0, flags [DF], proto UDP (17), length 778) 192.168.1.101.53305 > 10.0.0.66.65000: UDP, length 750 Now let's send IPv6 packet 14:17:16.740525 fa:16:3e:8f:d6:95 > fa:16:3e:a3:46:61, ethertype IPv6 (0x86dd), length 8254: (flowlabel 0x056c0, hlim 255, next-header UDP (17) payload length: 8200) 2001:db8:2222:3333:f816:3eff:fe8f:d695.59603 > 2620:52:0:13b8::fe:a5.65000: [bad udp cksum 0xeb30 -> 0x65d7!] UDP, length 8192 14:17:16.740676 fa:16:3e:8f:d6:95 > fa:16:3e:a3:46:61, ethertype IPv6 (0x86dd), length 812: (flowlabel 0x056c0, hlim 255, next-header UDP (17) payload length: 758) 2001:db8:2222:3333:f816:3eff:fe8f:d695.59603 > 2620:52:0:13b8::fe:a5.65000: [bad udp cksum 0xce1e -> 0x247f!] UDP, length 750 6 packets captured 6 packets received by filter 0 packets dropped by kernel [2] IPv6 ----- [cloud-user@rhel-int ~]$ ping6 -s 8800 2620:52:0:13b8::fe:a5 PING 2620:52:0:13b8::fe:a5(2620:52:0:13b8::fe:a5) 8800 data bytes 8808 bytes from 2620:52:0:13b8::fe:a5: icmp_seq=1 ttl=63 time=2.76 ms 8808 bytes from 2620:52:0:13b8::fe:a5: icmp_seq=2 ttl=63 time=1.46 ms ^C --- 2620:52:0:13b8::fe:a5 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 3ms rtt min/avg/max/mdev = 1.458/2.110/2.762/0.652 ms [cloud-user@rhel-int ~]$ ping6 -s 8900 2620:52:0:13b8::fe:a5 PING 2620:52:0:13b8::fe:a5(2620:52:0:13b8::fe:a5) 8900 data bytes ^C --- 2620:52:0:13b8::fe:a5 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 28ms [cloud-user@rhel-int ~]$ ip -6 route get 2620:52:0:13b8::fe:a5 2620:52:0:13b8::fe:a5 via fe80::f816:3eff:fea3:4661 dev eth0 proto ra src 2001:db8:2222:3333:f816:3eff:fe8f:d695 metric 1024 hoplimit 255 pref medium Path MTU value is not set (because ICMP 'fragmentation needed' was not sent) - not OK IPv4 ----- [cloud-user@rhel-int ~]$ ip route get 10.0.0.66 10.0.0.66 via 192.168.1.1 dev eth0 src 192.168.1.101 uid 1000 cache [cloud-user@rhel-int ~]$ ping -s 8900 10.0.0.66 PING 10.0.0.66 (10.0.0.66) 8900(8928) bytes of data. From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1482) From 192.168.1.1 icmp_seq=2 Frag needed and DF set (mtu = 1482) ^C --- 10.0.0.66 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3ms [cloud-user@rhel-int ~]$ ip route get 10.0.0.66 10.0.0.66 via 192.168.1.1 dev eth0 src 192.168.1.101 uid 1000 cache expires 596sec mtu 1482 <=== Path MTU value is set - OK [3] Tracepath IPv4 - OK ------------ [cloud-user@rhel-int ~]$ tracepath -n 10.0.0.1 1?: [LOCALHOST] pmtu 8942 1: no reply 2: 192.168.1.1 2.971ms pmtu 1482 2: 10.0.0.1 2.374ms !H Resume: pmtu 1482 IPv6 - not OK ------ [cloud-user@rhel-int ~]$ tracepath6 -n 2620:52:0:13b8::fe:a5 1?: [LOCALHOST] 0.033ms pmtu 8942 1: no reply 2: no reply 3: no reply 4: no reply 5: no reply
Please ignore mentions of missing ICMP 'fragmentation needed' because in case of IPv6 we need to get Packet Too Big ICMPv6 message, probably a separate RFE should be for this. But I would expect IPv6 packets respect Neutron network MTU setting.
I filled BZ for the issue in RHOSP 17.0 https://bugzilla.redhat.com/show_bug.cgi?id=2162083