6.6. Networking

In cluster environment, the multicast traffic from the guest to a host can be unreliable. To work around this problem, enable multicast_querier for the bridge. The setting is located in the /sys/class/net/<bridge_name>/bridge/multicast_querier file. Note that if the setting is not available, the problem should not occur.

A missing part of the bcma driver causes the brcmsmac driver not to load automatically when the bcma driver scans the for devices. This causes the kernel not to load the brcmsmac module automatically on boot. Symptoms can be confirmed by running the lspci -v command for the device and noting the driver to be bmca, not brcmsmac. To load the driver manually, run modprobe brcmsmac on the command line.

Under certain conditions, when the server is processing multiple outgoing replication or windows sync agreements using the TLS or SSL protocol, and processing incoming client requests that use TLS or SSL and Simple Paged Results, the server becomes unresponsive to new incoming client requests. The dirsrv service will stop responding to new incoming client requests. A restart of the dirsrv service is required to restore service.

When some Fibre Channel over Ethernet (FCoE) switch ports connected to the bfa host bus adapter go offline and then return in the online state, the bfa port may not re-establish the connection with the switch. This is due to a failure of the bfa driver's retry logic when interacting with certain switches. To work around this problem, reset the bfa link. This can be done either by running:

]# echo 1 > /sys/class/fc_host/host/issue_lip

or by running:

]# modprobe -r bfa && modprobe bfa

For HP systems running in HP FlexFabric mode, the designated iSCSI function can only be used for iSCSI offload related operations and will not be able to perform any other Layer 2 networking tasks, for example, DHCP. In the case of iSCSI boot from SAN, the same SAN MAC address is exposed to both the corresponding ifconfig record and the iSCSI Boot Firmware Table (iBFT), therefore, Anaconda will skip the network selection prompt and will attempt to acquire the IP address as specified by iBFT. If DHCP is desired, Anaconda will attempt to acquire DHCP using this iSCSI function, which will fail and Anaconda will then try to acquire DHCP indefinitely. To work around this problem, if DHCP is desired, the user must use the asknetwork installation parameter and provide a "dummy" static IP address to the corresponding network interface of the iSCSI function. This prevents Anaconda from entering an infinite loop and allows it to request the iSCSI offload function to perform DHCP acquisition instead.

If the corresponding network interface has not been brought up by dracut or the tools from the iscsi-initiator-utils package, this prevents the correct MAC address from matching the offload interface, and host bus adapter (HBA) mode will not work without manual intervention to bring the corresponding network interface up. To work around this problem, the user must select the corresponding Layer 2 network interface when anaconda prompts the user to choose "which network interface to install through". This will inherently bring up the offload interface for the installation.

When an igb link us up, the following ethtool fields display incorrect values as follows:

End-to-End (E2E) slaves that communicated with an E2E master once can synchronize to Peer-to-Peer (P2P) masters and vice versa. The slaves cannot update their path delay value because E2E ports reject peer delay requests from P2P ports. However, E2E ports accept SYNC messages from P2P ports and the slaves keep updating clock frequency based on undesired offset values that are calculated by using the old path delay value. Therefore, a time gap will occur if the master port is started with an incorrect delay mechanism. The "delay request on P2P" or "pdelay_req on E2E port" message can appear. To work around these problems, use a single delay mechanism for one PTP communication path. Also, because E2E and P2P mismatch can trigger a time gap of slave clock, pay attention to the configuration when starting or restarting a node on a running domain.

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

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.

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.

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 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 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.