[Gentoo]MTU gaat "spontaan" op 576 zitten op router WAN

[dion_b]

Situatie:

Wegens nieuwe internetverbinding voldeed een P3-533 met 2x 100Mbit/s NICs niet meer. Eisen waren 2x Gb NICs en een CPU die geen bottleneck zou zijn (en liefst niet al te onzuinig was). Toevallig had ik een bak liggen die als HTPC bedoeld was en een goede NIC onboard had waar ik ook al Linux op had draaien. Dus daar even een tweede NIC ingepropt, X uitgezet en routing aangezet.

Specs:
Intel DG35EC mobo, E2180 CPU, 2GB RAM, 160GB en 500GB SATA HDDs (router is tegelijk ook homeserver), onboard Intel 82566 NIC, losse Realtek RTL8169 PCI erbij.

Linux:
Gentoo. Kernel 2.6.25-r6 (van Gentoo sources gebakken).

Netwerk:
Deze router zit op LAN kant via Gbit switch met overige PCs verbonden, aan WAN kant met een kabelmodem met Gbit full duplex interconnect. Alle settings aan WAN kant gaan via DHCP

Klaar? Eerste keer testen (achter een andere router) wel. Maar toen ik het direct op de modem aansloot bleek de router zelf internetverbinding te hebben, maar bakken erachter niet. Opvallend genoeg konden ze wel voorbij de router pingen en DNS lookups doen. Na wat gepruts bleek het probleem te zitten in het feit dat de WAN NIC (Intel geval) spontaan een MTU van 576 bleek te krijgen waar de LAN 1500 had.

Tijdelijke oplossing:

code:

ifconfig eth0 mtu 1500

Daarna werkt alles weer tot de volgende reboot.

Dus op zoek gegaan naar waar het fout gaat.

dmesg|grep eth0 geeft het volgende:

code:

heisenberg / # dmesg|grep eth0
eth0: (PCI Express:2.5GB/s:Width x1) 00:1c:c0:52:d2:98
eth0: Intel(R) PRO/1000 Network Connection
eth0: MAC: 4, PHY: 6, PBA No: ffffff-0ff
eth0: Link is Up 1000 Mbps Full Duplex, Flow Control: None
eth0: changing MTU from 1500 to 576

*iets* lijkt dus m'n NIC te vertellen naar 576 te gaan nadat het up komt met 1500 MTU.

Vervolgens in heel /etc met grep -R 576 gezocht, maar 576 komt alleen ergens in m'n SSL certs voor

Hier ben ik een beetje vastgelopen. Ik heb twee verschillende modems geprobeerd om te zien of dat wat uitmaakt, m'n nieuwe Cisco/Scientific Atlanta EPC3000 en m'n oude Arris TM402B. Maakte niets uit. Ik heb de NICs omgedraaid (dus even in /etc/udev/rules.d/70-persistent-net.rules eth0 en eth1 verwisseld en fysiek de kabels omgewisseld). De RTL8169 kreeg toen ook 576, de e1000e 1500. Het lag niet aan de drivers, maar aan iets wat eth0 eigen was...


Dit is ongeveer waar ik vastgelopen ben. Hier is m'n iptables -L:

code:

heisenberg dion_b # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
REJECT     udp  --  anywhere             anywhere            udp dpt:bootps reject-with icmp-port-unreachable
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
REJECT     udp  --  anywhere             anywhere            udp dpt:domain reject-with icmp-port-unreachable
REJECT     udp  --  anywhere             anywhere            udp dpt:bootps reject-with icmp-port-unreachable
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh
DROP       tcp  --  anywhere             anywhere            tcp dpts:0:1023
DROP       udp  --  anywhere             anywhere            udp dpts:0:1023

Chain FORWARD (policy DROP)
target     prot opt source               destination
DROP       all  --  anywhere             192.168.0.0/16
ACCEPT     all  --  192.168.0.0/16       anywhere
ACCEPT     all  --  anywhere             192.168.0.0/16

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Daarbij heb ik dit document gevolgd muv dat zij eth1 voor LAN en eth0 voor WAN nemen en ik omgekeerd.

Opmerkelijk:
Ik lees als mogelijke oplossing voor MTU problemen om het volgende te proberen:

code:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

- maar als ik dat probeer krijg ik deze fout:

code:

iptables: No chain/target/match by that name

Iemand een idee?

[deadinspace]

Hmm, als je een andere computer met GNU/Linux of Windows aan je kabelmodem hangt, krijgen die dan ook een MTU van 576?

dion_b schreef op dinsdag 22 juli 2008 @ 22:47:
aan WAN kant met een kabelmodem met Gbit full duplex interconnect. Alle settings aan WAN kant gaan via DHCP

Het zou kunnen dat de DHCP server van de provider die MTU doorgeeft. Hier (op Debian met dhcp3-client) staan de DHCP leases in /var/lib/dhcp3 . Je zou daar eens kunnen kijken of je iets van een MTU kan ontdekken. Zo niet, dan is greppen op 576 in /var misschien een idee.

Tijdelijke oplossing:

code:

ifconfig eth0 mtu 1500

Daarna werkt alles weer tot de volgende reboot.

Het is interessant om te bepalen wanneer het terugspringt naar 576. Een reboot is natuurlijk nogal drastisch, wat als je de interface up en down doet of opnieuw DHCPt? Je kan ook proberen of het wel optreedt als je path MTU discovery uitzet. Dat kan door een 1 te schrijven naar /proc/sys/net/ipv4/ip_no_pmtu_disc .

Maakte niets uit. Ik heb de NICs omgedraaid (dus even in /etc/udev/rules.d/70-persistent-net.rules eth0 en eth1 verwisseld en fysiek de kabels omgewisseld). De RTL8169 kreeg toen ook 576, de e1000e 1500.

Kreeg je bij je RTL8169 ook exact die "changing MTU from 1500 to 576" melding in je logs?

Ik lees als mogelijke oplossing voor MTU problemen om het volgende te proberen:

code:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Voorzover ik kan vertellen zal dit niets veranderen aan de MTU op je eth0, maar zou het er wel voor moeten zorgen dat je met een MTU van 576 op je eth0 toch fatsoenlijk kan internetten op de computers achter je router.

De regel is bedoeld voor als ergens in het pad van jou naar een server op het internet de MTU te klein is voor je packets. In dat geval wordt vanaf die plek een ICMP Fragmentation Needed teruggestuurd, en de zendende computer past dan de grootte van de verstuurde packets aan. Maar soms worden die ICMP FN packets ergens geblokkeerd waardoor de grootte niet aangepast wordt, met brakheid tot gevolg.

Die iptables regel inject een aangepaste MSS (Maximum Segment Size) in elke beginnende TCP verbinding, waardoor op alle verbindingen meteen al kleinere packets afgedwongen worden. Met --clamp-mss-to-pmtu zet hij die MSS op de kleinste MTU die hij kent min 40, in jouw geval waarschijnlijk 576 - 40 = 536 dus.

- maar als ik dat probeer krijg ik deze fout:

code:

iptables: No chain/target/match by that name

En nadat je

modprobe ipt_TCPMSS

doet?

Oh, en een random tip:
Ik heb op mijn gateway/router de interfaces wan0 en lan0 genoemd, wat ik best handig vind. Hoef je niet telkens naar de IP adressen te kijken om er achter te komen welke ook al weer de externe was. Kun je gewoon in die udev rules aanpassen. Je zult dan alleen wel nog wat dingen zoals je firewall aan moeten passen.

[koffiedrinker]

Dat had ik tijden geleden ook met mijn Casema/Wanadoo verbinding
Je kan dit als volgt aanpassen in de file: /etc/conf.d/net:
Hier is de passage uit net.example:

code:

# Some users may need to alter the MTU - here's how
#mtu_eth0="1500"

En dan wordt het dus ook onthouden bij een herstart

[ Voor 10% gewijzigd door koffiedrinker op 23-07-2008 22:28 ]

[dion_b]

deadinspace schreef op woensdag 23 juli 2008 @ 00:03:
Hmm, als je een andere computer met GNU/Linux of Windows aan je kabelmodem hangt, krijgen die dan ook een MTU van 576?

[...]

Het zou kunnen dat de DHCP server van de provider die MTU doorgeeft. Hier (op Debian met dhcp3-client) staan de DHCP leases in /var/lib/dhcp3 . Je zou daar eens kunnen kijken of je iets van een MTU kan ontdekken. Zo niet, dan is greppen op 576 in /var misschien een idee.

dhcpcd hiero - en inderdaad, daar komt die 576 vandaan... staat doodleuk in /var/lib/dhcpcd/dhcpcd-eth0.info

Het is interessant om te bepalen wanneer het terugspringt naar 576. Een reboot is natuurlijk nogal drastisch, wat als je de interface up en down doet of opnieuw DHCPt?

Bij DHCP idd.

[...]

Kreeg je bij je RTL8169 ook exact die "changing MTU from 1500 to 576" melding in je logs?

Ja, exact hetzelfde.

[...]

Voorzover ik kan vertellen zal dit niets veranderen aan de MTU op je eth0, maar zou het er wel voor moeten zorgen dat je met een MTU van 576 op je eth0 toch fatsoenlijk kan internetten op de computers achter je router.

De regel is bedoeld voor als ergens in het pad van jou naar een server op het internet de MTU te klein is voor je packets. In dat geval wordt vanaf die plek een ICMP Fragmentation Needed teruggestuurd, en de zendende computer past dan de grootte van de verstuurde packets aan. Maar soms worden die ICMP FN packets ergens geblokkeerd waardoor de grootte niet aangepast wordt, met brakheid tot gevolg.

Die iptables regel inject een aangepaste MSS (Maximum Segment Size) in elke beginnende TCP verbinding, waardoor op alle verbindingen meteen al kleinere packets afgedwongen worden. Met --clamp-mss-to-pmtu zet hij die MSS op de kleinste MTU die hij kent min 40, in jouw geval waarschijnlijk 576 - 40 = 536 dus.

Tnx, helder

[...]

En nadat je

modprobe ipt_TCPMSS

doet?

Aanvankelijk niets. Volledig monolithic kernel. Heb het herbakken met TCPMSS support. Nu werkt het wel

Oh, en een random tip:
Ik heb op mijn gateway/router de interfaces wan0 en lan0 genoemd, wat ik best handig vind. Hoef je niet telkens naar de IP adressen te kijken om er achter te komen welke ook al weer de externe was. Kun je gewoon in die udev rules aanpassen. Je zult dan alleen wel nog wat dingen zoals je firewall aan moeten passen.

Mwoeah, ik heb heel standaard eth0 voor WAN en eth1 voor LAN. Dat vergeet ik niet zo snel.

Maar goed, was overduidelijk een DHCP setting. Ben nu in contact aan het treden met ISP hierover (ik test eea voor hen, dus dit is exact soort feedback dat ze willen). 576 is nou niet regular breedband, laat staan voor hoge snelheden.

koffiedrinker schreef op woensdag 23 juli 2008 @ 22:27:
Dat had ik tijden geleden ook met mijn Casema/Wanadoo verbinding
Je kan dit als volgt aanpassen in de file: /etc/conf.d/net:
Hier is de passage uit net.example:

code:

# Some users may need to alter the MTU - here's how
#mtu_eth0="1500"

En dan wordt het dus ook onthouden bij een herstart

Dit is idd makkelijkste workaround totdat de DHCP server een gezonde MTU gaat aanraden. Tnx