Setting MTU via DHCP

JKnott

It does via making changes to the registry.. Which yeah pretty simple to roll out any sort of reg entry you want.

What happens with a notebook, where the user takes it to a another network? Does that registry setting still apply?

BTW, my only experience with AD is resetting passwords.

JKnott

As I mentioned, there has been some discussion about moving the Internet to jumbo frames, as the conditions that drove the smaller MTUs no longer exist.

Jumbo Frame Deployment at Internet Exchange Points (IXPs)

Hurricane Electric is a major Internet backbone provider.

kiokoman

yes the registry will not change, at this point you can create a simple .bat script that will change that value based on where you are or buy a second network card to use only with mtu 9000 set it and forget

JKnott

@kiokoman said in Setting MTU via DHCP:

yes the registry will not change, at this point you can create a simple .bat script that will change that value based on where you are or buy a second network card to use only with mtu 9000 set it and forget

And you're back to having manually change something that should be done automagically. As I said, a DHCP client should adjust itself to the network, without any user intervention. This is definitely a "feature" in Windows.

I was at IBM when DHCP started to become popular. I had my own static ip (9.29.146.147), which I used in my office, but I had to reconfigure when I went to another site. Someone at IBM came up with a utility for OS/2, which I could use to select different profiles, according to where I was. However, the switch to DHCP removed the need for that, other than switching between my static IP and DHCP. Funny thing, my current notebook computer, running Linux, still has that ability, where I can run a variety of profiles. As someone who frequently connects to customer networks and often needs a static configuration, that is quite handy, but it's not available in Windows.

kiokoman

that was an expired draft from back 2011
it's interesting what is written in the attached pdf https://ripe63.ripe.net/presentations/129-Jumbo_Frames_RIPE63_Nov2011.pdf

Pros and Cons: summary
Cons
1.No standard/agreement for size of Jumbo Frames
2.Increase transmission time, packet delay, jitter, etc.
3.Require bigger buffers on equipment
4.PMTUD doesn’t work
5.Low traffic with the current maximum size

Pros
1.Less CPU load
2.Less network packet overhead
3.Better TCP performance

30 4. Pros and Cons: applications

Cons
1.Inter-process communication (IPC)
2.Protocols using small packets (DNS, VoIP, etc)
3.Interoperability (no standards, broken PMTUD)

Pros
1.Data transfer (Backups/Clusters/NFS/NNTP)
2.VPNs with payload 1500 bytes
3.SAN (FCoE/iSCSI)

31 4. Conclusion Personal
1.Nature of Internet traffic: small packets
2.All talks about Jumbo Frames are similar to IPv6 talks: started in 90x but IPv4 addresses are over and Ethernet with 1500 bytes still works fine

The performance advantages are small.
The implementation headache can be significant.

In my opinion, Jumbo Frames aren't worth the effort. Equipment vendors have really optimized the heck out of 1500MTU packet delivery.
to gain only maybe 2% in real usage
http://www.boche.net/blog/2011/01/24/jumbo-frames-comparison-testing-with-ip-storage-and-vmotion/
This comparison is from 2011,
With the cpu power we have now i bet is less than 2%
too many cons vs pros

johnpoz

@kiokoman said in Setting MTU via DHCP:

In my opinion, Jumbo Frames aren't worth the effort.

Exactly!! They might have niche use cases.. But in your typical network - especially in a home with all kinds of different devices wanting to talk to each other.. Your media player wanting to pull your movies off your nas going to support them? That wireless roku stick you use to watch your plex or stream your music library, etc.

Your pc printing to your "wireless" connected printer - sure great use case for jumbo there.. Make as BIG as possible ;) You know to shave off cpu time <rolleyes>..

Add up ALL the devices in your network that interact with each other.. So ok you can shave 1/8 of 1% of cpu for the 20 seconds it takes to move a movie from your pc to your nas.. What about all the other devices pulling stuff that nas when the nas wants and things the network mtu is 9000..

If you want to use jumbo on the SAN you use to backup your nas to your other nas - Go for it, might see some advantage there.. But for your overall network - just not worth it..

To windows machine not pulling the mtu from dhcp - really talk about a niche issue.. How many home users boxes running windows even connected to a wired network these days? ;)

Nischi

Thanks everyone for their replies. I didn't mean to stir up any conflicts here regarding use cases. This is purely for my own educational reasons in a home/lab-environment.

JKnott

@johnpoz said in Setting MTU via DHCP:

To windows machine not pulling the mtu from dhcp - really talk about a niche issue.. How many home users boxes running windows even connected to a wired network these days? ;)

Same applies to WiFi, though the max MTU is much less than 9K. As for home users, how many of them connect to Google? Might not Google benefit from jumbo frames? They can't if the user can't use them. Can you imagine what things would be like if we were forced to use 576, as was often the case years ago. Given Internet2 is already running 9000 MTU, there's no reason why the regular Intermet couldn't be switched to it too. I'm not saying there should be a flag day, when everyone switches to 9000, but just stop putting the 1500 limit in. Arbitrary limits should never be forced, as sooner or later they will bite.

This is in some ways the same argument people use for not moving to IPv6. They claim the current situation is OK and no improvement is needed. Well, that's not the way the world works. IPv4 stopped being adequate the day NAT became necessary and given the huge increase in traffic over the years, 1500 MTU has become a performance barrier.

JKnott

@kiokoman said in Setting MTU via DHCP:

that was an expired draft from back 2011
it's interesting what is written in the attached pdf https://ripe63.ripe.net/presentations/129-Jumbo_Frames_RIPE63_Nov2011.pdf

Pros and Cons: summary
Cons
1.No standard/agreement for size of Jumbo Frames

9000 is often used, as in Internet2

2.Increase transmission time, packet delay, jitter, etc.

1500 was the standard back in the days of 10 Mb half duplex Ethernet. Now it's typically 1 or even 10 Gb FD.

3.Require bigger buffers on equipment

Not an issue these days with large cheap memory.

4.PMTUD doesn’t work

It's mandatory on IPv6 and IPv4 is already moving to it. With Linux, PMTUD is used for everything, on Windows TCP now has the do not fragment flag set.

5.Low traffic with the current maximum size

What of all those web pages people read? Are they all under 1500 bytes? Streaming audio/video over TCP? On the other hand VoIP does use small packets.

Pros
1.Less CPU load
2.Less network packet overhead
3.Better TCP performance

30 4. Pros and Cons: applications

Cons
1.Inter-process communication (IPC)
2.Protocols using small packets (DNS, VoIP, etc)
3.Interoperability (no standards, broken PMTUD)

Having 9000 MTU available does not mean it will be used exclusively. As before, packet size varies, according to what's needed and what's supported. So, if you're downloading large files, then large MTU is what you want. If you only need small packets then that's what you use.

Pros
1.Data transfer (Backups/Clusters/NFS/NNTP)
2.VPNs with payload 1500 bytes
3.SAN (FCoE/iSCSI)

31 4. Conclusion Personal
1.Nature of Internet traffic: small packets
2.All talks about Jumbo Frames are similar to IPv6 talks: started in 90x but IPv4 addresses are over and Ethernet with 1500 bytes still works fine

See my previous post, but that's generally a "head in the sand" attitude.

The performance advantages are small.

Tell that to the people who build high performance routers and networks.

The implementation headache can be significant.

Why? 9000 and more MTU is now common on a lot of equipment. If your equipment is not capable, then don't run it. What's beyond the router is irrelevant. Incidentally, I ran a test with 9000 MTU on my network a while ago and the only thing that couldn't handle it was the WiFi AP, due to it's own MTU limitation. I did not test with other appliances, but my computers, unmanaged switch, etc. worked fine. One hard limit for home, small office users would be the WiFi MTU (2304), if the access point is connected directly to the LAN. If it passes through a router first, then it's no longer an issue.

In my opinion, Jumbo Frames aren't worth the effort. Equipment vendors have really optimized the heck out of 1500MTU packet delivery.
to gain only maybe 2% in real usage
http://www.boche.net/blog/2011/01/24/jumbo-frames-comparison-testing-with-ip-storage-and-vmotion/
This comparison is from 2011,
With the cpu power we have now i bet is less than 2%
too many cons vs pros

Funny thing about that PDF. It seems a lot of the objection is "people don't like change". Well that's the case for a lot of things in life. I was just reading a book about time and frequency from the NIST and it mentioned people were even opposed to standard time zones, even before we get to the debate about daylight savings time. People just don't like change, even though that change may make things better for them. I also read in that PDF about the performance calculations, where they considered just the more data per header issue, but not router performance, due to fewer packets.

That PDF also refers to 802.3 frames, when IP runs over DIX II frames, which are similar, but not the same as 802.3. A big difference is there's no maximum payload size or frame length specified for DIX II. 802.3 has that hard 1500 byte payload limit, but with DIX II, the frame ends when the frame ends. There is no field in the frame that says otherwise. The frame sizes listed in that PDF are related to that 802.3 limit, not DIX II. One thing that PDF doesn't mention is that 802.3 requires LLC/SNAP to get the same functionality as the Ethertype frame in DIX II. That counts for a few more bytes. However, these days I doubt you'll find 802.3 being used for much beyond spanning tree. It's certainly not used with IP. And yes, I am well aware that back in the early days memory size & cost were a factor in going with 1500 bytes, but that no longer applies.

BTW, many years ago, I hand wired some Ethernet controllers on Data General Eclipse prototyping boards. Back then chip count really mattered, whereas today Ethernet controller chips are used, instead of the discrete logic as was used on the boards I built.

JKnott

@Nischi said in Setting MTU via DHCP:

I didn't mean to stir up any conflicts here regarding use cases.

We're just getting started!

This is purely for my own educational reasons in a home/lab-environment.

Excellent reason, one that I have often used. You can learn a lot that way.

However, one thing that really gets me are the head in the sand types, who argue against change, because they've always done it that way. That's a real innovation killer.

kiokoman

yes i'm putting my head in the sand but tell me, what do i have to do? i can't set MTU on my phone, i have to manually set MTU on windows, i can't set MTU on my IOT and you can't have mixed MTU device on the same LAN, my ISP does not support 9000
all this trouble to gain maybe 1%
of course i put my head in the sand, to hell with MTU, you have to tell your reasons to all the other ISP out there, to all the manufacturer of phone and iot, modem, router etc etc. when it will be the stardard i will think about it.

@Nischi said in Setting MTU via DHCP:

Thanks everyone for their replies. I didn't mean to stir up any conflicts

we are having fun here, an exchange of constructive thoughts, that's what a forum is for, intellingent people can discuss without hard feelings

This is purely for my own educational reasons in a home/lab-environment.

test test test do something wrong and test again that's the best way to learn, don't trust us do your test and see for yourself

johnpoz

@JKnott said in Setting MTU via DHCP:

head in the sand types, who argue against change,

Dude so your running jumbo on your home network??? Come on - let me know how you set your printer to use jumbo.. Did you hack up some of your own firmware and driver for its nic? Shouldn't it just pick up the mtu from dhcpd - oh wait it doesn't do that either... WTF ;)

This is not head in the sand - this is just common sense, I have no use for this PITA since there is no main stream support for it as of yet... If everything on my network supported jumbo... Then it would be the new standard and we wouldn't having this discussion in the first place.

It's kind of like your attitude towards ipv6.. You have it in your head that its the STANDARD, and required.. No matter how much you want it to be.. It just not here yet.. How many iot devices support it... how many actual isp support it? etc etc. Name 1 major internet resource that I can only get to on ipv6.. You can not..

Its just like this jumbo nonsense... Sorry but it has no use... Maybe when we are all running 40gig on local networks it will be, but currently sorry its just not the case.. How about you get with all the iot makers to get their shit to do jumbos and then maybe we can have a discussion on why not running it ;)

You know what while your talking to them - ask them why they put a freaking 10/100 nic in a 4K tv? What the gig nic would of cost what a $1 more or something? Or also have them support wpa enterprise vs this nonsense psk, so I can run eap-tls on them..

The OP can do what ever he wants... His original question about mtu and dhcp has nothing to do with pfsense at all.. It's a windows issue.. Take it up on their forums if you don't like how they are doing it... But the overall big picture is its pointless anyway.. Nobody is running jumbo in home network - NOBODY!! At least nobody with any common sense, because the gain is not worth the effort and hassle. And in the corp world, if some IT guy had the smart idea to try and run jumbo on the users network.. He wouldn't be working there long ;) Love to be on the cab where he was discussing making that change ;)

I am more than happy to help you test and play with jumbo in your "lab" or for fun - but here is what your going to find out.. Its not fun, nor is provide any actual real world performance gain ;) Its not "fun" because all you run into is headaches on why doesn't this piece of shit support jumbo.. What do you mean this maker thinks jumbo size is this, and this maker thinks its that... You mean there is not actual standard they "have" to follow for the size?? WTF... Yeah this is the future for sure ;) You mean when I pick jumbo on this device and jumbo on that device and they don't match up exactly the flow of data between them is going to be way slower and cause the cpu to do way more work... who would of thunk it ;)

We can all talk about pie in the sky, oh they doing this oh they got this working, etc.. Still waiting on my freaking flying car.. But in the mean time while we wait for that there are actual cars... Just like sure super extra special large jumbo frames might be the thing when we have quantum computers and 100G wireless and 1TB wired connections.. But most of us live in the real world where I just want my TV to play my video off my nas and not stutter and or freeze or cause any issues.. Guess what gig and "standard" 1500 mtu does that.. Because EVERYTHING uses it...

JKnott

@kiokoman said in Setting MTU via DHCP:

es i'm putting my head in the sand but tell me, what do i have to do? i can't set MTU on my phone, i have to manually set MTU on windows, i can't set MTU on my IOT and you can't have mixed MTU device on the same LAN, my ISP does not support 9000

How do you know your phone won't support 9000? Android is based on Linux and MacOS on BSD, just like pfSense. I guess I've have to do some packet capture when the phone boots up, to see if it asks for MTU. As for your network, first off what's beyond your router is irrelevant for this discussion. You are correct in that everything directly connected (no routers in between) must also support the larger MTU. Otherwise you'll find packets being dropped by devices that can't read the larger frames. As for the gains, I've maintained the advantage is 6x the data per frame. That means less load on the CPUs in routers and computers. That might not make a difference to you, but does to the likes of Google. If all the Interent between you and Google supported jumbo frames, then Google will benefit, along with the carriers & ISP. As mentioned, the data saved with fewer headers is negligible. My point is allow larger MTU whenever possible. So, Google could set their MTU to 9000, but the router to the carrier will force traffic to 1500. Later, after that carrier allows 9000, then the next hop will limit. Eventually, however, there may be a path that supports 9000 all the way, as is the case with Internet2. All it takes it for the various parties involved to stop putting on a 1500 MTU. The Internet has always supported different MTUs and had the mechanism to deal with it, initially fragmentation and now path MTU discovery. So, if everything on your network supports jumbo frames (I haven't forgotten about WiFi), then you can use it for as far as it takes you. Perhaps some day, your ISP will support 9000 and you'll be ready!

JKnott

@johnpoz said in Setting MTU via DHCP:

Dude so your running jumbo on your home network??? Come on - let me know how you set your printer to use jumbo.

I have experimented with jumbo frames and they do work. However, since WiFi doesn't support them and my AP is connected directly to the LAN, I can't run jumbo frames on a regular basis.

It's kind of like your attitude towards ipv6.. You have it in your head that its the STANDARD, and required.. No matter how much you want it to be.. It just not here yet.. How many iot devices support it... how many actual isp support it? etc etc. Name 1 major internet resource that I can only get to on ipv6.. You can not..

IPv4 has not been adequate for years, as there are not enough addresses to go around. As a result, we have hacks like NAT and STUN to get around that. Yes, we should all move to IPv6 because IPv4 is not adequate. While I am not personally aware of servers that I cannot reach, there are large parts of the world where IPv6 is widely used, as IPv4 addresses are not available. There are also many who can only get NAT/RFC1918 addresses, which means they have no way to reach their own network from elsewhere. That alone proves IPv4 is not adequate.

Its just like this jumbo nonsense... Sorry but it has no use... Maybe when we are all running 40gig on local networks it will be, but currently sorry its just not the case.. How about you get with all the iot makers to get their shit to do jumbos and then maybe we can have a discussion on why not running it ;)

As I mentioned, some carriers and ISPs are already moving to 100 Gb. One that I have experience with, though not at 100 G is Cogeco Peer 1 (Peer 1 has recently split from Cogeco). So 100 Gb is on the way, though not at the consumer level.

Funny you should mention that. I bought a new TV a couple of months ago. It connects at 1 Gb. In fact the only thing on my network that doesn't, is my AP. However, that TV did mess up the WPA2 password, in that it won't accept the full 63 characters.

The OP can do what ever he wants... His original question about mtu and dhcp has nothing to do with pfsense at all.. It's a windows issue.

Yes it is a Windows issue as the DHCP client should work with any MTU. There's a long list of things Microsoft broke over the years. However, as it provides the DHCP server, pfSense should support any MTU and it does.