Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.


View this topic in a long page with up to 500 replies per page Create new topic
1 | 2 | 3 | 4 
fe31nz
1294 posts

Uber Geek
+1 received by user: 423


  #3094533 24-Jun-2023 19:12
Send private message

It does not quite work like that.  Officially, the MTU is the size of the data (payload) in an IP packet.  It does not include the headers or checksums.  However, the name MTU is also slightly misused for other things in routers, in this case for the size of the payload of the Ethernet frames.

 

The IP protocol does not do VLANs, that is part of the Ethernet protocol.  So the VLAN headers, when used, are added to the existing Ethernet headers, and are not part of the Ethernet payload, let alone the IP payload, so are not counted in the MTU value.  You can have multiple VLANs embedded in each other and so have multiple VLAN headers added to the Ethernet headers.  That is all handled automatically by the Ethernet drivers, not the TCP/IP stack.  So the MTU values do not need to be adjusted to account for the use of VLANs (or not).

 

The payload part of the Ethernet frames is where the IP packets are send, encapsulated inside the Ethernet frames.  So the full length of the IP packets is all data to the Ethernet frames.  The size of the Ethernet payload needs to be set in a router, and an "MTU" value is normally used for this.  But the MTU setting here specifies the data size of the IP packets, not including the IP headers and checksums.  The router adds the standard size of the IP headers to the MTU setting it has been given and uses that calculated value as the actual payload size for the Ethernet frames.

 

PPPoE is part of the IP protocols, and its headers are in the IP packet, inside the Ethernet frame's payload.  When you configure an Ethernet port in a router, that port only calculates its frame size from the given MTU value on the assumption that it will be having IP packets in the payload.  If you configure the payload to be PPPoE, then there are another 8 bytes of PPP headers added to the payload that the router does not put into its calculation.  So you need to increase the MTU value by 8 to account for that.

 

 

 

So the result is that these settings should be used:

 

 

 

1) When not using PPPoE:

 

Set the router's Ethernet WAN port MTU to 1500 (the default MTU for IP packets on Ethernet).

 

If using VLAN 10, set the VLAN 10 MTU to 1500.

 

 

 

2) When using PPPoE and your ISP and fibre provider have overprovisioning in place to allow for the extra 8 bytes of PPP headers (as is the case everywhere in NZ as far as I know, for fibre and VDSL):

 

Set the router's Ethernet WAN port MTU to 1508.

 

If using VLAN 10, set the VLAN 10 MTU to 1508.

 

Set the PPPoE MTU to 1500.

 

 

 

3) When using PPPoE and your ISP or fibre provider does not do overprovisioning, or your router does not support MTUs greater than 1500:

 

Set the router Ethernet WAN port MTU to 1500.

 

Set the VLAN 10 port MTU to 1500.

 

Set the PPPoE MTU to 1492.

 

If using IPv6, set the router to put an MTU of 1492 in its Router Advertisement (RA) packets.  Failing to do this or some other such workaround will result in IPv6 being broken as IPv6 packets in the MTU 1493-1500 range will be silently dropped when attempting to pass through the PPP connection in either direction.  This is due to the long-standing PPP software bug that it does not send ICMPv6 packets when it drops IPv6 packets, contrary to the requirements of IPv6.




BMarquis
466 posts

Ultimate Geek
+1 received by user: 581

Trusted
Chorus
Lifetime subscriber

  #3094596 25-Jun-2023 09:07
Send private message

While most of what you say there is right, MTU is relative to the interface it is configured on.
Some routers abstract it to the point where you dont actually know what you are setting.
i.e some router web GUIs ask for an MTU for a WAN interface, that they actually apply to the ethernet port. Some expect that MTU to be IP payload. there's not much consistancy.

What is important is to understand *where* the MTU you are configuring is being applied and what needs to be included.

At the Ethernet port level, the VLAN absoluely does need to be accounted for in the MTU if your RSP has asked for a VLAN tagged service from Chorus/the LFC.

In Tim's case (the context of my reply!) he said:
"Changed the MTU on the main ethernet interface with ifconfig enp4s0 mtu 1518 up"

As that was set on the Ethernet interface it needs to account for all overheads heading out on the the wire up to, and including the Ethernet layer. At that interface, you do not want to be setting a payload MTU of 1500, you want payload+PPP+Ethernet (VLAN is part of the Ethernet headers)

So, Tim will want an MTU on that Ethernet interface of 1522. If Tim's RSP had a tagged UFB service, then 1526 would be the correct MTU on that Ethernet interface.

timwelch

93 posts

Master Geek
+1 received by user: 14


  #3094621 25-Jun-2023 10:29
Send private message

Thanks @fe31nz and @BMarquis - this is the sort of discussion I was hoping to provoke and get answers such as this.

This thread should serve as a good reference!

 



Unfortunately in changing the MTU to 1522 I still get the same results. c'est la vie.

 

 

enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1522 qdisc mq state UP group default qlen 1000
    link/ether 60:32:b1:06:ec:21 brd ff:ff:ff:ff:ff:ff

 

ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet xxx.xxx.xxx.xxx peer xxx.xxx.xxx.34/32 scope global ppp0
       valid_lft forever preferred_lft forever
    inet6 fe80::7d58:dbb2:91bf:646e peer fe80::f0:aa9/128 scope link 
       valid_lft forever preferred_lft forever

 

Speedtest by Ookla

 

Server: Vetta Online - Christchurch (id: 42535)
ISP: Vetta Online
Idle Latency:    43.52 ms   (jitter: 0.64ms, low: 43.14ms, high: 44.14ms)
    Download:  1209.54 Mbps (data used: 1.5 GB)                                                   
                214.13 ms   (jitter: 62.07ms, low: 42.07ms, high: 1774.92ms)
      Upload:   154.40 Mbps (data used: 271.0 MB)                                                   
                 42.66 ms   (jitter: 3.11ms, low: 42.06ms, high: 334.38ms)
 Packet Loss: Not available.
  Result URL: https://www.speedtest.net/result/c/61145ec6-44dd-4672-8f59-f6ac98d46fee

 







timwelch

93 posts

Master Geek
+1 received by user: 14


  #3094624 25-Jun-2023 10:39
Send private message

and then the same test again with the MTU on ethernet set to 1492 for reference

 

3: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1492 qdisc mq state UP group default qlen 1000
    link/ether 60:32:b1:06:ec:21 brd ff:ff:ff:ff:ff:ff
9: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1484 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet xxx.xxx.xxx.xxx peer xxx.xxx.xxx.34/32 scope global ppp0
       valid_lft forever preferred_lft forever
    inet6 fe80::c66:65b5:4ecc:8cb peer fe80::f0:aae/128 scope link 
       valid_lft forever preferred_lft forever
user@debian:~$ speedtest -s 42535

 

   Speedtest by Ookla

 

      Server: Vetta Online - Christchurch (id: 42535)
         ISP: Vetta Online
Idle Latency:    43.32 ms   (jitter: 0.30ms, low: 42.96ms, high: 43.52ms)
    Download:  1245.12 Mbps (data used: 1.9 GB)                                                   
                152.31 ms   (jitter: 52.29ms, low: 42.36ms, high: 806.39ms)
      Upload:   213.11 Mbps (data used: 328.8 MB)                                                   
                 42.77 ms   (jitter: 5.10ms, low: 42.02ms, high: 332.59ms)
 Packet Loss: Not available.
  Result URL: https://www.speedtest.net/result/c/f731d42a-3c8f-4953-b94c-a9d543e25679

 





OmniouS
434 posts

Ultimate Geek
+1 received by user: 46

Trusted
Lifetime subscriber

  #3094626 25-Jun-2023 10:49
Send private message

The speed tests that you've posted all utilise 'Vetta Online - Christchurch (id: 42535)'.

 

Do you get similar results with other local servers?


BMarquis
466 posts

Ultimate Geek
+1 received by user: 581

Trusted
Chorus
Lifetime subscriber

  #3094632 25-Jun-2023 11:00
Send private message

Yeah... I do not expect the MTU to be the issue you are seeing here.


 
 
 

Want to support Geekzone and browse the site without the ads? Subscribe to Geekzone now (monthly, annual and lifetime options).
timwelch

93 posts

Master Geek
+1 received by user: 14


  #3094633 25-Jun-2023 11:03
Send private message

OmniouS:

 

The speed tests that you've posted all utilise 'Vetta Online - Christchurch (id: 42535)'.

 

Do you get similar results with other local servers?

 

 

Yeah, multiple different servers, even different ISPs... hence my reasoning for starting this thread ISP agnostic.





timwelch

93 posts

Master Geek
+1 received by user: 14


  #3094634 25-Jun-2023 11:05
Send private message

BMarquis: Yeah... I do not expect the MTU to be the issue you are seeing here.

 

Sigh... for now I done everything I'm able to. Might just wait for @quic to provision their IPoE...





1 | 2 | 3 | 4 
View this topic in a long page with up to 500 replies per page Create new topic








Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.