correct syntax for ETHTOO_OPTS in ifcfg file CentOS7.9
correct syntax for ETHTOO_OPTS in ifcfg file CentOS7.9
I can configure network interfaces as required from command line, like below, but my attempt to make the change persistent using ETHOOL_OPTS fails.
Example for one of the ifcfg files below. Any suggestions? Thank you
[root@localhost]# ethtool -s enp24s0f0 advertise 0x1000
[root@localhost]# systemctl stop network
[root@localhost]# systemctl start network
ifcfg-enp24s0f0
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=enp24s0f0
UUID=76c44b57-6d4b-433a-96cc-337c88147fd0
DEVICE=enp24s0f0
ONBOOT=yes
IPADDR=192.168.1.1
PREFIX=24
ETHTOOL_OPTS="advertise 0x1000"
Example for one of the ifcfg files below. Any suggestions? Thank you
[root@localhost]# ethtool -s enp24s0f0 advertise 0x1000
[root@localhost]# systemctl stop network
[root@localhost]# systemctl start network
ifcfg-enp24s0f0
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=enp24s0f0
UUID=76c44b57-6d4b-433a-96cc-337c88147fd0
DEVICE=enp24s0f0
ONBOOT=yes
IPADDR=192.168.1.1
PREFIX=24
ETHTOOL_OPTS="advertise 0x1000"
-
- Posts: 1464
- Joined: 2014/05/21 20:16:00
- Location: Central New York, USA
Re: correct syntax for ETHTOO_OPTS in ifcfg file CentOS7.9
I expect it's just me, but the file you posted lists ETHTOOL_OPTS, not ETHOOL_OPTS.
- just throwing that out there - in case helpful.
- just throwing that out there - in case helpful.
Re: correct syntax for ETHTOO_OPTS in ifcfg file CentOS7.9
This is the syntax that works for me:
Code: Select all
ETHTOOL_OPTS="-L ${DEVICE} combined 15"
CentOS 8 died a premature death at the end of 2021 - migrate to Rocky/Alma/OEL/Springdale ASAP.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are dead, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are dead, do not use them.
Use the FAQ Luke
Re: correct syntax for ETHTOO_OPTS in ifcfg file CentOS7.9
Network functions do contain:
The "advertise 0x1000" does not contain semicolons, so it is "one word". There are no hyphens either.
Therefore, network.service should call:
Trevor's "-L ${DEVICE} combined 15" contains hyphen, so it should invoke:
Both look equally good.
The ifcfg-enp24s0f0 looks like it might have been generated by NetworkManager (NM).
Yet, you restart network.service. If you do have NM in the system, then network.service probably does not manage this connection.
Code: Select all
ethtool_set()
{
oldifs=$IFS;
IFS=';';
if [ -n "${ETHTOOL_DELAY}" ]; then
# Convert microseconds to seconds:
local ETHTOOL_DELAY_SEC=$(convert2sec ${ETHTOOL_DELAY} micro)
sleep ${ETHTOOL_DELAY_SEC}
fi
for opts in $ETHTOOL_OPTS ; do
IFS=$oldifs;
if [[ "${opts}" =~ [[:space:]]*- ]]; then
/sbin/ethtool $opts
else
/sbin/ethtool -s ${REALDEVICE} $opts
fi
IFS=';';
done
IFS=$oldifs;
}
Therefore, network.service should call:
Code: Select all
/sbin/ethtool -s ${REALDEVICE} advertise 0x1000
Code: Select all
/sbin/ethtool -L ${DEVICE} combined 15
The ifcfg-enp24s0f0 looks like it might have been generated by NetworkManager (NM).
Yet, you restart network.service. If you do have NM in the system, then network.service probably does not manage this connection.
Re: correct syntax for ETHTOO_OPTS in ifcfg file CentOS7.9
Yes, thank you, I'll do as offered : ETHTOOL_OPTS="-s ${DEVICE} advertise 0x1000"jlehtone wrote: ↑2021/07/03 14:04:54Network functions do contain:The "advertise 0x1000" does not contain semicolons, so it is "one word". There are no hyphens either.Code: Select all
ethtool_set() { oldifs=$IFS; IFS=';'; if [ -n "${ETHTOOL_DELAY}" ]; then # Convert microseconds to seconds: local ETHTOOL_DELAY_SEC=$(convert2sec ${ETHTOOL_DELAY} micro) sleep ${ETHTOOL_DELAY_SEC} fi for opts in $ETHTOOL_OPTS ; do IFS=$oldifs; if [[ "${opts}" =~ [[:space:]]*- ]]; then /sbin/ethtool $opts else /sbin/ethtool -s ${REALDEVICE} $opts fi IFS=';'; done IFS=$oldifs; }
Therefore, network.service should call:Trevor's "-L ${DEVICE} combined 15" contains hyphen, so it should invoke:Code: Select all
/sbin/ethtool -s ${REALDEVICE} advertise 0x1000
Both look equally good.Code: Select all
/sbin/ethtool -L ${DEVICE} combined 15
The ifcfg-enp24s0f0 looks like it might have been generated by NetworkManager (NM).
Yet, you restart network.service. If you do have NM in the system, then network.service probably does not manage this connection.
And yes all intrfaces that I need to manage ifcfg-enp24s0f0, ifcfg-enp24s0f1, ifcfg-enp24s0f2, ifcfg-enp24s0f3 are generated by NM. While I'm educating myself about NM and network connections managed, I would appreciate some pointers how to make this change persistent. Thank you.
Re: correct syntax for ETHTOO_OPTS in ifcfg file CentOS7.9
All works now, needed to disable NM.
Thank you for help!
Thank you for help!
Re: correct syntax for ETHTOO_OPTS in ifcfg file CentOS7.9
Systemd starts services.
Services read user choices stored in files and modify kernel's state accordingly. For example, "configure a network interface".
Services may use tools, like ip, ethtool, brctl, and iptables to talk with the kernel.
Only one service may configure a given interface; network.service and NetworkManager.service are mutually exclusive per interface.
It is possible to have one interface managed by NM and other by network.service.
The network.service has existed a long time. It has got many features.
Red Hat has evolved the file format that the network.service does use. It is quite human-readable.
The network.service is essentially one-shot scripts that run at boot and shutdown.
NetworkManager.service has shorter history. It has different philosophy than network.service.
It has its own file format, "NM settings", but can also read/write the config files that network.service uses.
Due to shorter history, NM has lacked some "exotic" features that network.service supports. However, NM in CentOS Linux 7
has improved substantially over the lifetime of CentOS Linux 7.
For some reason the list of NM settings (see man nm-settings) is not 1:1 the command line parameters that one can give to nmcli.
The nmcli does modify the config files.
The documentation of NM does show that it does support ethtool options. It most likely calls "ethtool". However, the translation from nmcli parameter, via NM settings, to how NM will call ethtool ... is poorly documented, or the support is incomplete.
For "normal" network NM is sufficient. Why do we tend to stay away from "normal"?
Services read user choices stored in files and modify kernel's state accordingly. For example, "configure a network interface".
Services may use tools, like ip, ethtool, brctl, and iptables to talk with the kernel.
Only one service may configure a given interface; network.service and NetworkManager.service are mutually exclusive per interface.
It is possible to have one interface managed by NM and other by network.service.
The network.service has existed a long time. It has got many features.
Red Hat has evolved the file format that the network.service does use. It is quite human-readable.
The network.service is essentially one-shot scripts that run at boot and shutdown.
NetworkManager.service has shorter history. It has different philosophy than network.service.
It has its own file format, "NM settings", but can also read/write the config files that network.service uses.
Due to shorter history, NM has lacked some "exotic" features that network.service supports. However, NM in CentOS Linux 7
has improved substantially over the lifetime of CentOS Linux 7.
For some reason the list of NM settings (see man nm-settings) is not 1:1 the command line parameters that one can give to nmcli.
The nmcli does modify the config files.
The documentation of NM does show that it does support ethtool options. It most likely calls "ethtool". However, the translation from nmcli parameter, via NM settings, to how NM will call ethtool ... is poorly documented, or the support is incomplete.
For "normal" network NM is sufficient. Why do we tend to stay away from "normal"?
