Moin,
> Note that I have also written some scapy script to test path MTU
> discovery. /usr/src/regress/sys/netinet/pmtu/tcp_connect.py
> and tcp_connect6.py
> Sometimes these tests fail, so PMTU may have bugs. Or my tests are
> just unreliable.
Awesome, thanks!
> How does the route look like where the path MTU is saved?
> netstat -rn has a Mtu column.
The MTU does not get saved on these routes, and remains at 0:
gw02.dus01.as59645.net ~ # route -T0 -n get 2a06:d1c0::b
route to: 2a06:d1c0::b
destination: 2a06:d1c0::b
mask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
gateway: 2a06:d1c0::dead:beef:a01
interface: vio0
if address: 2a06:d1c0::dead:beef:a02
priority: 48 (bgp)
flags: <UP,GATEWAY,DONE>
label: lpbck
use mtu expire
2 0 0
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA,LABEL>
gw02.dus01.as59645.net ~ # route -T0 -n get 195.191.197.154
route to: 195.191.197.154
destination: 195.191.197.154
mask: 255.255.255.255
gateway: 195.191.197.226
interface: vio0
if address: 195.191.197.225
priority: 48 (bgp)
flags: <UP,GATEWAY,DONE>
label: lpbck
use mtu expire
2929947 0 0
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA,LABEL>
> I see lines like this in the dump.
> 12:52:50.064789 2a06:d1c0::2.179 > 2a06:d1c0::b.54616: P
> 69:2147(2078) ack 83 win 1023 <nop,nop,timestamp 3903202654
> 2152766359>: BGP (UPDATE: (Path attributes: (ORIGIN[T] IGP)
>
> Packet size 2078 seems large. Do use jumbo frames?
> On which machine did you make the tcpdump? OpenBSD?
The switched path between DUS and AMS has an MTU of 9000, but the
router interfaces on either side are still on 1500.
> You should disable TCP Segmentation Offload. Otherwise you never
> know the packet sizes on the wire.
> sysctl net.inet.tcp.tso=0
gw02.dus01 is a virtual 7.4 with virtio; IIRC it should not have tso
then (yet); But I will disable TSO on the system and give this another
try.
> Note that OpenBSD supports Large Receive Offload only on ix(4).
> Other hardware interface don't do it.
> ifconfig ix0 -tcplro
> On Linux you can use ethtool to disable offloading.
>
> Does packet size change in tcpdump when you turm off TSO?
I honestly fully missed this; Let me grab a new pcap from a bridge not
meddling with TSO etc.
The pcap is from gw01.ams01, btw.; So technically there should not have
been any TSO meddling involved; Let me check how that came to be.
With best regards,
Tobias
