UXG-Lite MTU problemen

Sinds een paar dagen heb ik een UXG-Lite als router voor mijn Freedom glasverbinding. Via een script zet ik de MTU naar de juiste waardes:

!/bin/sh

Replace 1492 with 1500 in /etc/ppp/peers/ppp0
sed -i ‘s/ 1492/ 1500/g’ /etc/ppp/peers/ppp0

Set MTU for eth1 and eth1.6
ip link set dev eth1 mtu 1512
ip link set dev eth1.6 mtu 1508

Bring eth1 down and then back up
ifconfig eth1 down
ifconfig eth1 up

Kill all pppd processes
killall pppd

ifconfig geeft dit resultaat:

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.1 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 2a10:x:289d::1 prefixlen 64 scopeid 0x0
inet6 fe80::dab3:70ff:fe93:b65e prefixlen 64 scopeid 0x20
ether d8:b3:70:93:b6:5e txqueuelen 1000 (Ethernet)
RX packets 376384 bytes 457595082 (436.3 MiB)
RX errors 0 dropped 21 overruns 0 frame 0
TX packets 327160 bytes 63673254 (60.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::dab3:70ff:fe93:b65e prefixlen 64 scopeid 0x20
ether d8:b3:70:93:b6:5e txqueuelen 1000 (Ethernet)
RX packets 769592 bytes 604496319 (576.4 MiB)
RX errors 0 dropped 104 overruns 392 frame 392
TX packets 714788 bytes 282419579 (269.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1512
inet6 fe80::dab3:70ff:fe93:b65f prefixlen 64 scopeid 0x20
ether d8:b3:70:93:b6:5f txqueuelen 1000 (Ethernet)
RX packets 415405 bytes 190668523 (181.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 53982
TX packets 545977 bytes 505506471 (482.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0.2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.254 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 2a10:x:289d:2::1 prefixlen 64 scopeid 0x0
inet6 fe80::dab3:70ff:fe93:b65e prefixlen 64 scopeid 0x20
ether d8:b3:70:93:b6:5e txqueuelen 1000 (Ethernet)
RX packets 226611 bytes 110307647 (105.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 252232 bytes 170667909 (162.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0.10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.16.0.254 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 2a10:x:289d:1::1 prefixlen 64 scopeid 0x0
inet6 fe80::dab3:70ff:fe93:b65e prefixlen 64 scopeid 0x20
ether d8:b3:70:93:b6:5e txqueuelen 1000 (Ethernet)
RX packets 1055 bytes 127403 (124.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 765 bytes 90063 (87.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0.1010: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.254 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 fe80::dab3:70ff:fe93:b65e prefixlen 64 scopeid 0x20
ether d8:b3:70:93:b6:5e txqueuelen 1000 (Ethernet)
RX packets 25015 bytes 3657882 (3.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 134221 bytes 46688078 (44.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth1.6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1508
inet6 fe80::dab3:70ff:fe93:b65f prefixlen 64 scopeid 0x20
ether d8:b3:70:93:b6:5f txqueuelen 1000 (Ethernet)
RX packets 407535 bytes 173316676 (165.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 545862 bytes 503996071 (480.6 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

honeypot0: flags=195<UP,BROADCAST,RUNNING,NOARP> mtu 1500
inet 192.168.1.99 netmask 255.255.255.255 broadcast 192.168.1.99
inet6 fe80::f008:5dff:fe8e:7a3d prefixlen 64 scopeid 0x20
ether f2:08:5d:8e:7a:3d txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 155729 bytes 156456230 (149.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 155729 bytes 156456230 (149.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 45.x.x.x.x netmask 255.255.255.255 destination 185.93.175.230
inet6 fe80::c965:92eb:11f6:1207 prefixlen 128 scopeid 0x20
ppp txqueuelen 3 (Point-to-Point Protocol)
RX packets 50075 bytes 28349875 (27.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 45420 bytes 13561180 (12.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Waar volgens mij alles goed lijkt te staan. Als ik ping met een MTU naar een ipv4 adres gaat dat goed:

ping radio.nl -c3 -s 1468 -M do
PING radio.nl (37.48.79.75) 1468(1496) bytes of data.
1476 bytes from 37.48.79.75 (37.48.79.75): icmp_seq=1 ttl=57 time=5.35 ms

Maar met een maximale MTU ipv6 waarde van 1452 bytes gaat het mis, en krijg ik geen antwoord.

ping freedom.nl -c3 -s 1452 -M do
PING freedom.nl(haproxy.frontproxy.fi001.nl.freedomnet.nl (2a10:3780:2:52:185:93:175:46)) 1452 data bytes
— freedom.nl ping statistics —
3 packets transmitted, 0 received, 100% packet loss, time 2008ms

Gewoon pingen naar een ipv6 adres gaat wel zonder problemen.

Heeft iemand een idee wat er fout zit in de configuratie?

Ik zie op mijn router dat zowel eth2.6 als eth2 een mtu van 1508 hebben volgens de uitvoer van ip a.

Bij mij werken die beide ping commando’s zonder problemen.

Beide op 1508 gezet, maar helaas blijft het probleem.

Als het goed is, verandert de MTU van eth1 automatisch zodra je die van eth1.6 aanpast.
Misschien kan je met een traceroute of met Wireshark meer zien?

Op zich wel opvallend dat ppp0 gewoon overeind komt met een MTU van 1500. Dat suggereert dat die hogere MTU in principe werkt. Misschien is het een stukje hardware packet accelerator wat hier speciaal mee omgaat? Ik gebruik een Turris Omnia en ik heb volgens mij gelezen dat PPP over VLAN6 niet optimaal ondersteund wordt ‘in hardware’ en dat er op software teruggevallen wordt.

1 like

De grotere MTU volgens RFC4638 is ook iets wat in het opzetten van de PPP verbinding onderhandeld moet worden tussen jouw apparaat en de concentrator bij de provider.

“Bij mij werkt dit” maar ik gebruik geen UXG-Lite. Bij OpenWRT weet ik dat dit ook goed gaat. Maar hoe dit bij UXG-Lite gaat zou je wellicht aan hun moeten vragen. Of eens een PPP sessie starten met debugging en kijken wat er gebeurt.

1 like

Het verkeer naar radio.nl stop je in PPP en mini-jumbo-frames. Die worden zonder meer geaccepteerd door de BRAS. Je ethernet-MTU kan dus prima mini-jumbo-frames aan. De BRAS kijkt niet naar de PPP-MTU van inkomend verkeer.

De host radio.nl stuurt IPv4 verkeer terug zonder dat het do-not-fragment bit is geset. Dat verkeer komt aan op de BRAS en die houdt bij het in PPP pakken wél rekening met de MTU. Die MTU is hoogstwaarschijnlijk 1492 byte. De BRAS zal het verkeer van radio.nl fragmenteren, waardoor het wel aankomt.

In IPv6 werk je met een end-to-end MTU. In dit geval vermoedelijk 1500 bytes; want 1452 bytes MTU resulteert in een 1500 byte pakket. De BRAS staat alleen 1492 bytes toe dus die dropt het terugkerende verkeer en stuurt packet-to-big berichten naar de verzender van dat packet. De verzender is in dit geval de host freedom.nl. Dat bericht krijg jij dus niet te zien.

Kortom, je ethernet-MTU is groot genoeg maar je PPP-MTU niet.

1 like