pfSense English Support > IPv6

Changing AdvLinkMTU when using NPt

(1/6) > >>

paddy76:
For various reasons I've opted to use NPt between my LAN and WAN. Because of this the MTU set in radvd.conf is wrong as it seems to be following the LAN side MTU when not using interface tracking.
This becomes an issue when using, for example, a GIF tunnel to HE as MTU has to be lowered to 1280.

For now I've fixed it by changing the services.inc file so it always sets AdvLinkMTU to 1280 instead of interface MTU if interface tracking is not used.

A more permanent solution would be if it were possible to manually set the MTU in the radvd gui configuration, follow option 26 from DHCPv6 or possibility to select interface that should be followed to get MTU for radvd.

JKnott:
One thing that's mandatory with IPv6 is path MTU discovery.  That means that a too small MTU along the path is automagically discovered and adjusted for.  If that didn't work, you couldn't use paths where a link had a smaller MTU than your LAN.  Does the different MTU actually cause a problem?  Having a different MTU on LAN vs WAN has always been part of networking.  Years ago, 576 was a common MTU for dial up links, yet connected just fine with Ethernet & 1500 byte MTU or token ring with 4K byte MTU.  The main difference back then was fragmentation of too large packets.  With IPv6 and even IPv4 now. MTU discovery is used to prevent too large packets from being sent, so fragmentation is no longer needed.

Also, for the first 6 years I had IPv6, I used a tunnel broker with 1280 MTU and never had a problem, even though my LAN was the usual 1500.


Dave M.:
I also modify services.inc to set the MTU to 1280. PMTU discovery is nice in theory but in practice too much traffic ends up going nowhere.

JKnott:

--- Quote from: Dave M. on October 29, 2017, 06:51:20 am ---I also modify services.inc to set the MTU to 1280. PMTU discovery is nice in theory but in practice too much traffic ends up going nowhere.

--- End quote ---

If it fails, it's because someone blocked ICMP somewhere.  IP has long been designed to work with smaller MTUs along the path and I've certainly not had a problem with MTU discovery.  For example, if someone has an ADSL connection, they'd normally have 1500 on the LAN, 1492 on the WAN and may hit 1280 somewhere, even without a tunnel.  IP has to deal with it and does.

As I mentioned above, I used a tunnel for 6 years and never had an issue with MTU.

Napsterbater:

--- Quote from: paddy76 on October 28, 2017, 05:36:18 pm ---For various reasons I've opted to use NPt between my LAN and WAN. Because of this the MTU set in radvd.conf is wrong as it seems to be following the LAN side MTU when not using interface tracking.
This becomes an issue when using, for example, a GIF tunnel to HE as MTU has to be lowered to 1280.

--- End quote ---

Ummm NPt has nothing to do with MTU, it is not the reason the "MTU is wrong" (its not). An Ethernet LAN has a MTU of 1500, thus will be advertised as such. It is NOT suposed to advertise that WAN MTU to the LAN.

Nothing is wrong with it advertising 1500 MTU, that is as designed/intended.

Navigation

[0] Message Index

[#] Next page

Go to full version