What are the req'd MTUs for FTTN wan- & lan-side ?

[blakers]

Following up on some MTU troubleshooting on the FTTN link

Can't post to Forums when on FTTN; ok via Sonic VPN?
viewtopic.php?f=10&t=2855&start=30#p19296

MTU certainly matters.

In the Pace 5031NV's settings I see a broadband status

Code: Select all

	Broadband
		Status
			Internet Details
				Broadband Link Type
					Built in modem - ADSL/VDSL
						MTU 1500   <======================

and on the next tab an EDITABLE manual configuration

Code: Select all

		Link Configuration
			Broadband IP Network
				Upstream MTU [1500]   <======================

I'd not set that value.

I don't know if it's

(a) a modem default
(b) obtained/populated from upstream DHCP

For a Sonic/FTTN connection (1x-pair, VDSL2) what ARE the required MTU settings for

(a) the Broadband side link (modem<->'net) of the modem
(b) the LAN side link (modem<->LAN) of my router

to NOT have packet transmission/loss problems?

[dherr]

If this varies by location then you might get more info at the U-verse forum at DSLreports. But here is my info...

I have X1 FTTN on a Pace 5031nv. The Pace is set for 1500 and my linux host is set the same. This is a direct wired connection (well there *is* a small switch in the path).

The pings are set to not fragment. The first shows that 1500 does get thru. The second shows that 1501 does not. So I do think this shows that 1500 is correct for a vanilla setup.

>ping -M dont -c2 -s 1472 ping.sonic.net
PING http://www.sonic.net (209.204.190.64) 1472(1500) bytes of data.
1480 bytes from http://www.sonic.net (209.204.190.64): icmp_seq=1 ttl=52 time=30.0 ms
1480 bytes from http://www.sonic.net (209.204.190.64): icmp_seq=2 ttl=52 time=29.7 ms

--- http://www.sonic.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 29.752/29.900/30.048/0.148 ms


>ping -M dont -c2 -s 1473 ping.sonic.net
PING http://www.sonic.net (209.204.190.64) 1473(1501) bytes of data.

--- http://www.sonic.net ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

[blakers]

> I have X1 FTTN on a Pace 5031nv.

check

> The Pace is set for 1500 and my linux host is set the same.

check

> This is a direct wired connection (well there *is* a small switch in the path).

check (one of several tested configs)

So we _do_ add the usual ppp* 28-byte overhead -- IP header (20) + ICMP Echo Request header (8). Is Uverse, in fact, pppoe?

Testing here with your examples

>>ping -M dont -c2 -s 1472 ping.sonic.net
> ...
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>
>>ping -M dont -c2 -s 1473 ping.sonic.net
> ...
> 2 packets transmitted, 0 received, 100% packet loss, time 999ms

I get exactly the same result. 1500 looks OK in general. Still not clear about that Sonic-forums specific issue.

Lacking an official stmt, this info is helpful.

It'll be useful to get that documented @ Sonic's MemberTools site for FTTN install/setup.

Thanks!

[toast0]

>
So we _do_ add the usual ppp* 28-byte overhead -- IP header (20) + ICMP Echo Request header (8). Is Uverse, in fact, pppoe?

Those 28 bytes are not ppp overhead, it's ICMP/IP overhead; in other words, for 1472 bytes of ping payload, you need to send 1500 bytes of ethernet payload (and typically 14 bytes of ethernet framing). FTTN is not PPPoE (yay!)

FTTN provides ipv6 via 6rd (if you choose to use it), given a MTU of 1500, the 6rd MTU should be 1480, but packets longer than 1472 seem to be dropped, so I lowered my MTU to 1472

[blakers]

> Those 28 bytes are not ppp overhead, it's ICMP/IP overhead ... FTTN is not PPPoE

Noted, thanks.

> FTTN provides ipv6 via 6rd (if you choose to use it) ...

I'll keep that in mind. IPv6 is a no go here on FTTN -- for now.

[kgc]

The load balancing configuration that we use on for these forums uses tunneling and requires a smaller MTU and we did not have MSS fixup in place. Something between us and the users that couldn't post had broken PMTUD (possibly the CPE or additional tunneled virtual circutis.) We enabled MSS fixup on our end which we probably should have put in place in the first place.