5.6. Networking

If configured, the Active Directory (AD) DNS server returns IPv4 and IPv6 addresses of an AD server. If the FreeIPA server cannot connect to the AD server with an IPv6 address, running the ipa trust-add command will fail even if it would be possible to use IPv4. To work around this problem, add the IPv4 address of the AD server to the /etc/hosts file. In this case, the FreeIPA server will use only the IPv4 address and executing ipa trust-add will be successful.

Destroying the root port before any NPIV ports can cause unexpected system behavior, including a full system crash. Note that one instance where the root port is destroyed before the NPIV ports is when the system is shut down. To work around this problem, destroy NPIV ports before destroying the root port that the NPIV ports were created on. This means that for each created NPIV port, the user should write to the sysfs vport_delete interface to delete that NPIV port. This should be done before the root port is destroyed. Users are advised to script the NPIV port deletion and configure the system such that the script is executed before the fcoe service is stopped, in the shutdown sequence.

A Linux LIO FCoE target causes the bfa driver to reset all FCoE targets which might lead to data corruption on LUN. To avoid these problems, do not use the bfa driver with a Linux FCoE target.

A GATEWAY setting in the /etc/sysconfig/network file causes NetworkManager to assign that gateway to all interfaces with static IP addresses, even if their configuration did not specify a gateway or specified a different gateway. Interfaces have the incorrect gateway information and the wrong interface may have the default route. Instead of using GATEWAY in /etc/sysconfig/network to specify which interface receives the default route, set DEFROUTE=no in each ifcfg file that should not have the default route. Any interface connected using configuration from an ifcfg file containing DEFROUTE=no will never receive the default route.

Typically, on platforms with no Intelligent Platform Management Interface (IPMI) hardware the user can see the following message the on the boot console and in dmesg log:

Could not set up I/O space

This message can be safely ignored, unless the system really does have IPMI hardware. In that case, the message indicates that the IPMI hardware could not be initialized. In order to support Advanced Configuration and Power Interface (ACPI) opregion access to IPMI functionality early in the boot, the IPMI driver has been statically linked with the kernel image. This means that the IPMI driver is "loaded" whether or not there is any hardware. The IPMI driver will try to initialize the IPMI hardware, but if there is no IPMI hardware present on the booting platform, the driver will print error messages on the console and in the dmesg log. Some of these error messages do not identify themselves as having been issued by the IPMI driver, so they can appear to be serious, when they are harmless.

Shutting down the fcoe-target service while the Fibre Channel over Ethernet (FCoE) can lead to a kernel crash. Please minimize FCoE traffic before stopping or restarting this service.

After an ixgbe Fibre Channel over Ethernet (FCoE) session is created, server reboot can cause some or all of the FCoE sessions to not be created automatically. To work around this problem, follow the following steps (assuming that eth0 is the missing NIC for the FCoE session):

ifconfig eth0 down
ifconfig eth0 up
sleep 5
dcbtool sc eth0 dcb on
sleep 5
dcbtool sc eth0 pfc e:1 a:1 w:1
dcbtool sc eth0 app:fcoe e:1 a:1 w:1
service fcoe restart

Using targetcli to configure the FCoE Target will fail with the message Could not create RTSRoot in configFS. To prevent this, ensure that the fcoe-target service is running by executing service fcoe-target start.

The InfiniBand UD transport test utility could become unresponsive when the ibv_ud_pingpong command was used with a packet size of 2048 or greater. UD is limited to no more than the smallest MTU of any point in the path between point A and B, which is between 0 and 4096 given that the largest MTU supported (but not the smallest nor required) is 4096. If the underlying Ethernet is jumbo frame capable, and with a 4096 IB MTU on an RoCE device, the max packet size that can be used with UD is 4012 bytes.

IPA creates a new DNS zone in two separate steps. When the new zone is created, it is invalid for a short period of time. A/AAAA records for the name server belonging to the new zone are created after this delay. Sometimes, BIND attempts to load this invalid zone and fails. In such a case, reload BIND by running either rndc reload or service named restart.

SELinux can prevent the nmbd service from writing into the /var/, which breaks NetBIOS name resolution and leads to SELinux AVC denials.

If multiple DHCP6 servers are configured on multiple VLANs, for example two DHCP6 servers on VLAN1 and VLAN3, the bna driver NIC does not set up a VLAN interface but can get the VLAN3 IPv6 address.

The latest version of the sfc NIC driver causes lower UDP and TX performance with large amounts of fragmented UDP packets. This problem can be avoided by setting a constant interrupt moderation period (not adaptive moderation) on both sides, sending and receiving.

When IPv6 is administratively disabled via disable=1 module parameter, all of the IPv6 protocol handlers are disabled. This includes any offload handlers that support TSO/GSO. The lack of handlers results in the host dropping any TSO/GSO IPv6 packets it may receive from the guest. This can cause problems with retransmission on the guest and throughput. If you want to disable IPV6 support on the host administratively while enabling and providing IPv6 support to the guest without incurring a performance penalty:

Some network interface cards (NICs) may not get an IPv4 address assigned after the system is rebooted. To work around this issue, add the following line to the /etc/sysconfig/network-scripts/ifcfg-<interface> file:

LINKDELAY=10

If a Certificate Authority (CA) certificate is not selected when configuring an 802.1x or WPA-Enterprise connection, a dialog appears indicating that a missing CA certificate is a security risk. This dialog presents two options: ignore the missing CA certificate and proceed with the insecure connection, or choose a CA certificate. If the user elects to choose a CA certificate, this dialog disappears and the user may select the CA certificate in the original configuration dialog.

Current Samba versions shipped with Red Hat Enterprise Linux 6.4 are not able to fully control the user and group database when using the ldapsam_compat back end. This back end was never designed to run a production LDAP and Samba environment for a long period of time. The ldapsam_compat back end was created as a tool to ease migration from historical Samba releases (version 2.2.x) to Samba version 3 and greater using the new ldapsam back end and the new LDAP schema. The ldapsam_compat back end lack various important LDAP attributes and object classes in order to fully provide full user and group management. In particular, it cannot allocate user and group IDs. In the Red Hat Enterprise Linux Reference Guide, it is pointed out that this back end is likely to be deprecated in future releases. Refer to Samba's documentation for instructions on how to migrate existing setups to the new LDAP schema.

When you are not able to upgrade to the new LDAP schema (though upgrading is strongly recommended and is the preferred solution), you may work around this issue by keeping a dedicated machine running an older version of Samba (v2.2.x) for the purpose of user account management. Alternatively, you can create user accounts with standard LDIF files. The important part is the assignment of user and group IDs. In that case, the old Samba 2.2 algorithmic mapping from Windows RIDs to Unix IDs is the following: user RID = UID * 2 + 1000, while for groups it is: group RID = GID * 2 + 1001. With these workarounds, users can continue using the ldapsam_compat back end with their existing LDAP setup even when all the above restrictions apply.

Because Red Hat Enterprise Linux 6.4 defaults to using Strict Reverse Path filtering, packets are dropped by default when the route for outbound traffic differs from the route of incoming traffic. This is in line with current recommended practice in RFC3704. For more information about this issue please refer to /usr/share/doc/kernel-doc-<version>/Documentation/networking/ip-sysctl.txt and https://access.redhat.com/site/solutions/53031.