HewlettPackard / HewlettPackard/PacketRusher
[BUG] inexact MTU calculation for PDU session interface
- Dominant language
- Go
- Stars
- 193
- Forks
- 47
- PR merge metrics
- No merged PRs in 30d
Description
**Describe the bug**
When PacketRusher creates a PDU session valXXXXXXXXXX interface, the MTU size calculation is off by 8 octets, which forces IPv4 fragmentation on the N3 network.
**To Reproduce**
Steps to reproduce the behavior:
1. Start PacketRusher with PDU session tunnel feature enabled.
2. Wait for PDU session establishment.
3. Observe the MTU of valXXXXXXXXXX interface and n3 interface.
4. Transmit an uplink ICMP ping at exactly the MTU size, and observe the traffic on n3 interface.
**Expected behavior**
MTU of valXXXXXXXXXX interface should be small enough so that uplink packets do not experience IPv4 fragmentation on n3 interface.
**Screenshots**
```text
ubuntu@N0:~$ docker exec gnb0 ip link
5: val7005551000: mtu 1464 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none
13785: n3@if13786: mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 52:de:ac:19:c3:12 brd ff:ff:ff:ff:ff:ff link-netnsid 0
```
**Architecture (please complete the following information):**
- OS: Docker 27.3.1 on Ubuntu 22.04
- Platform: amd64
- Version: fd83fec05d964cab7a16fe0d55ff230dd6d9a77a
- Kernel: 5.15.0-127-lowlatency with gtp5g v0.9.6
**Log:**
```text
time="2025-01-03T21:33:54Z" level=info msg="[UE][GTP] Interface val7005551000 has successfully been configured for UE 10.1.0.1"
time="2025-01-03T21:33:54Z" level=info msg="[UE][GTP] You can do traffic for this UE by binding to IP 10.1.0.1, eg:"
time="2025-01-03T21:33:54Z" level=info msg="[UE][GTP] iperf3 -B 10.1.0.1 -c IPERF_SERVER -p PORT -t 9000"
```
**Pcap:**
Packet trace: [2.pcapng.gz](https://github.com/user-attachments/files/18304169/2.pcapng.gz)

**Additional context**
Outer IPv4 header has 20 octets; outer UDP header has 8 octets; GTPv1 header including PDU Session Container extension has 16 octets.
Total header overhead is 44 octets, so that valXXXXXXXXXX interface MTU should be 1500-44=1456 octets.
While this does not prevent communication, it is a performance overhead as the UPF now has to perform IPv4 reassembly.
This is most likely a regression introduced during #135 QFI implementation.
Contributor guide
Research direction
Start by tracing where PacketRusher configures the valXXXXXXXXXX PDU session interface MTU and compare it with the N3 encapsulation overhead described in the issue. Reproduce the exact-MTU ICMP case and verify that the interface MTU accounts for 44 octets of overhead and avoids IPv4 fragmentation on N3.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100