RHEL 6.3: Loss of Network connectivity after service action



Source

RETAIN tip: H21436

Symptom

Users may encounter a loss of network connectivity on systems running Red Hat Enterprise Linux (RHEL) 6.3, or later following a service repair action involving the replacement of one (1) or more of the following components:

  • System board
  • Network adapter
  • Fiber Channel adapter
  • internet Small Computer System Interface (iSCSI) adapter

Note: The type of component or Field Replaceable Unit (replacement part number) number is not a factor.

Affected configurations

The system is configured with at least one of the following:

  • Red Hat Enterprise Linux 6, update 3

This tip is not system specific.

This tip is not option specific.

Note: This does not imply that the network operating system will work under all combinations of hardware and software.

Please see the compatibility page for more information:

http://www.ibm.com/systems/info/x86servers/serverproven/compat/us/

The system has the symptom described above.

Workaround

There are two (2) workarounds to correct this issue. Both can be performed by the user or field technician. Both workarounds require root access.

Workaround 1 (Before replacement of component):

  1. Obtain the Media Access Control (MAC) addresses from the new components.

  2. Edit the files '/etc/udev/rules.d/70-persistent-net.rules' and '/etc/sysconfig/network-scripts/ifcfg-ethX'(where: 'X' is the Network Interface Controller (NIC) number) to have the new cards MAC address before shutting down to install the card.

Notes:

System board On-Board NICs can be found printed on the system board, usually in the location of the NIC ports. They also can be found from the Unified Extensible Firmware Interface (UEFI) Basic Input/Output System (BIOS) under Network Settings.

Any other add-in component usually will be printed on the packaging or the card itself.

Some adapters do not list all the MAC addresses on the packages, only port 0. The only way to obtain MAC addresses for all ports is after the operating System loads the '70-persistent-net' file. (In these cases, users must employ Workaround 2.)

Workaround 2 (After replacement of component):

  1. Create a '/ntemp' directory that will be used to store the files in the following instructions.
    For example:
      [localhost#]mkdir /ntemp

  2. Move the files '/etc/udev/rules.d/70-persistent-net.rules' and '/etc/sysconfig/network-scripts/ifcfg-ethX' (where: 'X' is the NIC number) to the '/ntemp' folder.
    Example:
      [localhost#]mv /etc/udev/rules.d/70-persistent-net.rules /ntemp
    [localhost#]mv /etc/sysconfig/network-scripts/ifcfg-eth* /ntemp

  3. Restart the machine. (During start, a new '70-persistent-net.rules' file will be created, which will force the operating system to rediscover the components).

  4. Once the operating system starts run the following command:
    For example:
      [localhost#]cat /etc/udev/rules.d/70-persistent-net.rules
    # This file was automatically generated by the '/lib/udev/write_net_rules'
    # program, run by the persistent-net-generator.rules rules file.
    #
    # You can modify it, as long as you keep each rule on a single
    # line, and change only the value of the NAME= key.
    # PCI device 0x8086:0x100e (e1000e) SUBSYSTEM=="net," ACTION=="add," DRIVERS=="?*," ATTR{address}=="<MAC ADDRESS OF NEW COMPONENT>," ATTR{type}=="1," KERNEL=="eth*," NAME="eth0"
    # PCI device 0x8086:0x100e (e1000e) SUBSYSTEM=="net," ACTION=="add," DRIVERS=="?*," ATTR{address}=="<MAC ADDRESS OF NEW COMPONENT>," ATTR{type}=="1," KERNEL=="eth*," NAME="eth1"
    # PCI device 0x8086:0x100e (e1000e) SUBSYSTEM=="net," ACTION=="add," DRIVERS=="?*," ATTR{address}=="<MAC ADDRESS OF NEW COMPONENT>," ATTR{type}=="1," KERNEL=="eth*," NAME="eth3"
    # PCI device 0x8086:0x100e (e1000e) SUBSYSTEM=="net," ACTION=="add," DRIVERS=="?*," ATTR{address}=="<MAC ADDRESS OF NEW COMPONENT>," ATTR{type}=="1," KERNEL=="eth*," NAME="eth2"

    Note: Some versions of Linux will enumerate the 'eth' ports backwards so in static Internet Protocol (IP) environments it may be difficult to know which MAC address should correspond to which network port. In these situations, it may be necessary to identify the ports. An easy way to do this is set a static IP address on each port starting with 'eth0' using the following command:

      [localhost#]ifconfig eth0 <valid IP address> netmask <valid netmask> up

    Note: The IP and netmask must be valid on the network being tested. It should be possible to ping on the network at this point.

  5. Using the <MAC ADDRESS OF NEW COMPONENT> for 'eth0,' 'eth1,' etc., update the corresponding files '<ifcfg-eth*>' that were placed in the '/ntemp' folder.
    For example:

      NAME="eth*" <<<* is the corresponding eth port
    BOOTPROTO=static
    MACADDR="<MAC ADDRESS OF NEW COMPONENT>" <<<Place the MAC address here. IPv6INIT=no
    DEVICE=eth0
    NETMASK=255.255.255.0MTU=""
    BROADCAST=0.0.0.255
    IPADDR=""
    NETWORK=""
    ONBOOT=yes

  6. Once this is complete move the files back to the 'network-scripts' folder.
    For example:
      [localhost#]mv /ntemp/ifcfg-eth* /etc/sysconfig/network-scripts

  7. After the files have been moved, issue the following command to restart the networking services.

      [localhost#] service network restart

    Shutting down interface eth0: Device state: 3 (disconnected)

    Shutting down loopback interface: [OK]

    Bringing up loopback interface: [OK]

    Bringing up interface eth0: Active connection state: activating

    Active connection path: /org/freedesktop/NetworkManager/ActiveConnection/5 state: activated

    Connection activated

  8. Network connectivity should be restored at this point.

Additional information

This is not related to any hardware failure.

This issue has been encountered only with RHEL 6.3 or later and involves a file named '70-persistent-net.rules' in RHEL 6.3.

Applicable countries and regions

 


Document id:  MIGR-5093226
Last modified:  2013-07-09
Copyright © 2014 IBM Corporation