mtu not persisting on reboot w/ igb

[ewhull]

I've look through a number of threads on this forum (including all the Jumbo Frame posts which state it's useless) and other FreeBSD sources (including man igb(4)) and can't for the life of me determine why my mtu settings aren't persisting during a reboot of FreeNAS.

My switch is a TP-Link TL-SG2008, which I've verified supports my MTU settings.

I've modified both my /etc/rc.conf and /etc/default/rc.conf to include:
ifconfig_igb0="mtu 9216"
ifconfig_igb1="mtu 9216"

And I've got no luck with being able to keep them persisting through a reboot.

I know I'm missing something.

Any suggestions appreciated.

Thanks,

Eric

 

[cyberjock]

Because you aren't supposed to edit the MTU in the fashion that you are. Read our manual at doc.freenas.org. It provides a specific example for how to set the MTU...

You are missing something.. the manual.

For the record, I'm not endorsing the use of jumbo frames in the slightest. In fact, because of the problems you are already having, I'm pretty sure you're on the ever-losing side of getting Jumbo frames to work, and work properly, for your network.

MTU is something that either you are a pro at, or you've never done it. Sure feels like you've never done it since the appropriate value is NOT 9216.

 

[DrKK]

I will answer the OP's original question.

The reason why it's not "persisting" after a reboot is probably because those directories are created on reboot from a pristine original. The way you probably modified those files modified only the currently created versions. There is a way to modify the main system files so that they are created as you please on reboot, but that's strongly dis-recommended, and in any case, will get blown away on the next software update.

So no, you are not really going to do the thing you want to do, anyway.

 

[ewhull]

I will answer the OP's original question.

The reason why it's not "persisting" after a reboot is probably because those directories are created on reboot from a pristine original. The way you probably modified those files modified only the currently created versions. There is a way to modify the main system files so that they are created as you please on reboot, but that's strongly dis-recommended, and in any case, will get blown away on the next software update.

So no, you are not really going to do the thing you want to do, anyway.

Thank you; that explains the behavior I was experiencing.

A bit of a follow up question then, if one is trying to create a lagg, the FreeNAS documentation states:

If any configured interfaces exist, delete them as lagg creation will fail if any interfaces are manually configured.

However the manual also states that MTU must be set as part of the Options string on an interface configuration.

However, some lagg options can only be set by editing the interface. For instance, since the MTU of a lagg is inherited from the interface, in order to set an MTU on a lagg you must set all the interfaces to the same MTU before creating the lagg.

Since MTU must be set prior to the creation of the lagg, is it even possible to modify the MTU of a lagg through the GUI?

edit: words and things

 

[ewhull]

Because you aren't supposed to edit the MTU in the fashion that you are. Read our manual at doc.freenas.org. It provides a specific example for how to set the MTU...

You are missing something.. the manual.

For the record, I'm not endorsing the use of jumbo frames in the slightest. In fact, because of the problems you are already having, I'm pretty sure you're on the ever-losing side of getting Jumbo frames to work, and work properly, for your network.

MTU is something that either you are a pro at, or you've never done it. Sure feels like you've never done it since the appropriate value is NOT 9216.

Unfortunately, IMO, the manual is less than clear. You are correct though regarding that I've never attempted this sort of configuration prior. My goal with using this server is deepen my understanding of the inter-dependencies of network and server architecture, and to also learn more about FreeBSD in the process.

It's odd, when configuring the MTU (I attempted MTU 9000 at first since that seems to the be the most common configuration amongst my systems), and attempting to verify that it was functioning through 'ping -s 9000 x.x.x.x', ping would need to be force closed using ctrl-c as I would get no console response. When I reduced the size of my ping, to 8950 for example, it would show that the ping was transmitted at 8958. None of my other systems made this modification. It was only after I set the MTU to 9216 that I could successfully ping -s 9000, but again, the system indicated that the size of the transmission was 9008.

Thank you for the response.

 

[cyberjock]

Oh my. You are even more confused than I thought. That's not an insult, that's just what I've seen.

ping -s doesn't even do what you want it to do. I can ping -s 9000 x.x.x.x despite not having jumbo frames and it *will* work. It's supposed to work. But the packets are resized down, then reassembled at the destination... observe..

[root@freenas] ~# ping -s 9000 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 9000 data bytes
9008 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=0.379 ms
9008 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.395 ms
9008 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.375 ms
9008 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.415 ms
^C
--- 192.168.2.1 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.375/0.391/0.415/0.016 ms
[root@freenas] ~# ping -s 16000 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 16000 data bytes
16008 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=0.532 ms
16008 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.509 ms
16008 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.510 ms
16008 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.492 ms
^C
--- 192.168.2.1 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.492/0.511/0.532/0.014 ms

Note that I was able to send what appears to be 16k packets without problems. My networking hardware doesn't even support 16k (9000 is the maximum). Also notice that both of mine didn't send 9000 bytes or 16000 bytes. It's a play on numbers when you do large packets and other things, and is NOT immediately obvious.

The disparity is due to CRC, VLAN tagging (if any), and other factors. We're really getting deep into networking at this point, which is where I'm going to kind of stop because it's stuff that is far beyond the scope of this forum (and I'm probably not the most ideal source to be getting that involved with networking).

This is just another example of why we tell people that jumbo frames are pure evil. If you don't understand all the crap behind the scenes you'll be given info that makes you think thing are very broken.

As for why your ping was locking up, I have no clue what was wrong. It locking up tends to make me thing you are using an invalid configuration (beyond just an MTU mismatch). Even with MTU mismatches you'll get errors and such from failed pings. But ping should never lock up, so something more sinister is at work.

To be honest, trying to learn about jumbo frames while trying to learn a new OS is not going to end well. There's too much deep-level knowledge that needs to be understood for the casual user to understand whether the problem is because of the hardware, because of the OS, or because they have something set wrong.

Jumbo frames are, quite honestly, basically useless with today's technology. The advantages that they provided a decade ago were because of limitations in processing power of network cards, etc. Those limitations were fixed long ago (and were basically forced to be fixed for 10Gb to really have good throughput without jumbo frames). Due to the trickle down effect with technology, even 1Gb cards have that overhead resolved easily unless you go with things like Realtek. But nobody runs actual servers with Realtek if they have more than 2 brain cells. So you're really spending time on what is a dying technology. Every day that you and I wake up and go to work is that much less likelihood that we'll ever seen jumbo frames again.

My recommendation would be to stick with the default MTUs and not really even invest your time in it. It's really just not valuable in today's world except in a very very few extreme cases. Those cases are almost always handled by people with degrees in networking and other technology and so they know exactly what they want to set the MTU at (and it's often not a nice number like 9000).