NICs Order

Home » CentOS » NICs Order
CentOS 10 Comments

Hi,

After installing CentOS 7 in a server with 2 NICs, system detects eth0
and eth1 in reserve order. I would like to have eth1 as eth0 and eth0 as eth1. I have forced HWADDR attribute in
/etc/sysconfig/network-scripts/ifcfg-etc{0,1}, but after rebooting, order is the same…

How can I solve it?

Thanks.

10 thoughts on - NICs Order

  • machine with multiple ports yet, but on 6 blowing up
    /etc/udev/rules.d/60-net.rules would make it select the interfaces by the same order as the MAC.

    UPDATE: I just checked my CentOS 6 box and it uses
    /etc/udev/rules.d/70-persistent-net.rules but in my CentOS 7 vm, I
    only see a different file altogether

    [raub@duckwitch ~]$ ls -l /etc/udev/rules.d/
    total 0
    -rw-r–r– 1 root root 0 Jul 25 2014 80-net-name-slot.rules
    [raub@duckwitch ~]$

  • The issue here may be systemd (I’ve seen/agree with the venting, this is another example). If you’re getting non-eth names there’s a program called biosdevname which may be deciding how to name NICs for you. If that’s the case then then the -net.rules may be ineffective unless the following is added as kernel command line parameters:

    net.ifnames=1 and biosdevname=0

    I need to add big cautions here, my experience with this is on Ubuntu (where it’s 70-net.rules) and a hardware platform which has 10 NICs. systemd/biosdevname… named the first six NICs ‘ens…’ and the last four ‘eth…’. ( I really do wish the developers would stop trying to decide what’s best for us and leave control in our hands or at least provide documentation which is easily findable that allows us to take control back. ). Web documentation at freedesktop.org says net.ifnames needs to be set to zero, I found just the opposite but if it doesn’t work for you try both before giving up. I know where to set these parameters on Ubuntu but you’ll have to find where on CentOS. Hope this helps.

    —– Original Message —–
    From: “Ricardo J. Barberis”
    To: “CentOS mailing list”
    Sent: Monday, February 1, 2016 8:31:42 AM
    Subject: Re: [CentOS] NICs order

    El Lunes 01/02/2016, Daniel Ruiz Molina escribió:

    You could put the MAC addresses in /etc/udev/rules.d/60-net.rules, e.g.:

    SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”11:22:33:aa:bb:cc”, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”eth0″
    SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”44:55:66:dd:ee:ff”, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”eth1″

    But that never worked reliably for me, no matter what I tried.

    In the end I had to use different names instead of eth0 and eth1, like:

    SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”11:22:33:aa:bb:cc”, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”nic0″
    SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”44:55:66:dd:ee:ff”, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”nic1″

    And also rename /etc/sysconfig/network-scripts/ifcfg-ethX to ifcfg-nicX and modify them accordingly.

    HTH,

    Ricardo J. Barberis Usuario Linux Nº 250625: http://counter.li.org/
    Usuario LFS Nº 5121: http://www.linuxfromscratch.org/
    Senior SysAdmin / IT Architect – http://www.DonWeb.com

  • El Lunes 01/02/2016, Leroy Tennison escribió:

    So far, this is my only big grip with systemd: It apparently never worked, though IME it only stopped working with recent versions of udev.

    I tried that (and several other combinations), but with net.ifnames=0 which is what the docs say:
    https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/

    Nevertheless, I was never able to reliably use eth0 and eth1, I even got to the point of adding ‘modprobe -r nic_module ; modprobe nic_module’
    to /etc/rc.d/rc.local to make it work, but it seemed a really ugly hack.

    Yeah, on CentOS 6 it aldo is that, on CentOS 7 it still works but I read somewhere that 60-net.rules was the new preferred name (and now it seems to be 80-net-setup-link.rules?)

    Amen :)

    Ah, should have tried this. I’m probably not going to try it though (I’m already accustomed to my new naming scheme) but it can be useful to the OP, thanks.


    Ricardo J. Barberis Usuario Linux Nº 250625: http://counter.li.org/
    Usuario LFS Nº 5121: http://www.linuxfromscratch.org/
    Senior SysAdmin / IT Architect – http://www.DonWeb.com

  • Just to clarify: net.ifnames=0 disables the systemd/udev interface renaming feature. biosdevname=0 disables the biosdevname interface renaming feature, which is completely separate. If you want the traditional, non-deterministic Linux interface naming, you must specify both.

    Also, if you add rules to /etc/udev/rules.d, you should rebuild your initrd.

  • Well, I tried that and it didn’t change the behavior, using 1 as a value did. Don’t know if there’s been tampering between freedesktop and Ubuntu 14.04LTS but that was my experience.

    Thanks for the information. I didn’t and it has been working for a while (through reboots), what bad thing(s) may happen if I don’t?

    —– Original Message —

  • Gordon Messmer wrote:
    to zero, I found just the opposite but if it doesn’t work for you try both before giving up. renaming feature. biosdevname=0 disables the biosdevname interface renaming feature, which is completely separate. If you want the traditional, non-deterministic Linux interface naming, you must specify both.

    You call it “deterministic”. I will note that it is, in fact, straight from Sun – 20 years ago, that was the naming on the Sparc Server that I
    first picked up sysadmin work. Which was fine… FOR SUN HARDWARE. For admins and users, it’s *really* NOT a great idea, given that the system could have a m/b from any OEM, and even trying to set up a std. kickstart is a pain with that, much less anything more arcane. Why ethx, with the option of adding the firmware MAC address, is such a bad idea, I have no clue. initrd.

    ?!?!?!?! THAT I had never considered, nor done, and I’m sure that in CentOS 6, I’ve changed things there, and just rebooted. Oh, great, I’m getting flashes of WinDoze.

    Thanks for that info, though. I need to remember that.

    mark

  • Once upon a time, m.roth@5-cent.us said:

    That’s only necessary for things that are initialized in the initrd. Unless you are using network boot, the initrd won’t have any of the network initialization, so rebuilding it is not necessary for changing network-related config (including udev rules).

  • Thanks for clarification. I’d noticed that dracut will specifically include those files, but haven’t seen docs about when or how it’s used. Given a couple of users who said things didn’t work for them, I
    thought rebuilding was the safest advice.