NIC's udev/ifcfg on RHEL5

[brian_31]

Please let know the pros and cons of defining the NIC's by udev rules vs. the ifcfg. Thanks in advance

Cheers

Brian.

[Matti_Kurkela]

Do you mean defining the names of the NICs in relation to their MAC addresses? Or setting all the NIC parameters through udev?

Here are some points. Whether these are pros, cons or information-only depend on what you're trying to achieve.

* udev rules for network interfaces are applied whenever a driver detects a new network interface (i.e. when loading a module or hot-plugging a NIC that is supported by an already-loaded module) and never after that.
(Technically udev is also used when a NIC is hot-unplugged or a driver for it is unloaded, but that is usually not interesting: as the interface is going away, its name is not important any more.)

* ifcfg-* settings are used each time you use ifup/ifdown commands. So if your udev rules specify one naming scheme and ifcfg-* specifies something different, I would expect the system to eventually use the names determined by the ifcfg-* files.

* system-config-network and other menu-based RHEL5 administration tools expect you to use ifcfg-*. When a new network interface is added and the system is rebooted, kudzu automatically creates an ifcfg-* file for it with the MAC address <-> interface name mapping included.

My opinion would be: if you use RHEL5 in anything close to the default configuration, use ifcfg-* for specifying NIC naming.

If you use RHEL5 as a stripped-down server platform, with most of the distribution-specific automation removed, do what you will; you obviously know enough to deal with heavily customized configurations.

But don't customize for the sake of customization itself: if your systems work more like BrianLinux than RHEL5, you will never be able to have a 100% carefree vacation time.

MK

[Don Mallory]

Also generally be careful of configurations that are outside of what Red Hat would like you to do. They tend to drop patches that include configuration changes to things the way they expect them to be. As a result, you may find after patching that one day, your system will not bring up any network interfaces.

With that in mind. I would recommend you stick to the ifcfg-* files for configuring your interfaces.

Also remember that all scripts in this area are executed, if you keep backups of something, keep them somewhere else.

Best regards,
Don

[brian_31]

Thanks MK!

One of our senior SA mentioned that "Udev rules as the best method to avoid the drift of NICs after a reboot." Is this a correct statement? Environment Default RHEL5.

Thanks

Brian.

[Alzhy]

Your Senior SA may be correct. By drift, you mean their ethN numbers could change following a reboot - right?

[brian_31]

Yes! But when we checked with RH they recommend only ifcfg* method rather than udev rules , so i am confused. Our config is default RHEL 5.

Thanks

Brian

[Matti_Kurkela · Accepted solution]

If your senior SA typically edits the ifcfg-* files by hand, s/he may be unaware of RHEL's automatic functionality in this sense.

If you let kudzu generate the basic ifcfg-* files when adding new network interfaces, and/or use the menu-based administration tools provided by RedHat, the "NIC drift problem" is a non-issue for you - RHEL 4 and later will automatically keep NIC names persistently associated with respective MAC addresses.

This feature was added in RHEL 4. When kudzu detects a new network interface, it creates a blank ifcfg-* file for it and writes into it the HWADDR= line which ties the NIC name into the card's MAC address.

Note: you should not confuse HWADDR= with MACADDR=. The latter ifcfg-* configuration line will *assign* a specified MAC address to a NIC. Using HWADDR and MACADDR together on the same NIC is not a good idea.

For backward compatibility, if the ifcfg-* file already exists but does not have a HWADDR= line, the system will behave just like RHEL 3 and older versions. In that case, NIC drift is a real possibility if system configuration is changed - unless something like udev rules are added.

If you remove the HWADDR= lines and then use udev to achieve the same result, you must expend effort to do something the system would already do for you. You also must be aware of the HWADDR mechanism and either disable it or take great care make sure all HWADDR= lines are removed from ifcfg-* files. I would find this rather silly.

You should ask your senior sysadmin *why* s/he thinks udev is better than the RHEL HWADDR system.

If you get an insightful answer, please share it with us.

But if you get an evasive answer, you the real reason is probably something like: "When RHEL 4 was released, the HWADDR mechanism made the system do something I didn't expect and understand. I didn't make the effort to really understand what is going on; I just found out the minimum required to configure the network just like with RHEL 3 and older. Later I learnt about udev from some documentation meant for a different distribution."

MK