6.6. Networking

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 incoming BIND requests where the password used is hashed using SSHA512, the server becomes unresponsive to new incoming client requests. A restart of the dirsrv service is required. As the server is unresponsive, restarting can require terminating the ns-slapd process by running the kill -9 command.

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.

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.

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.

The bind-dyndb-ldap library incorrectly compares current time and the expiration time of the Kerberos ticket used for authentication to an LDAP server. As a consequence, the Kerberos ticket is not renewed under certain circumstances, which causes the connection to the LDAP server to fail. The connection failure often happens after a BIND service reload is triggered by the logrotate utility, and you need to run the pkill -9 named command to terminate BIND after a deadlock occurs. To work around this problem, set the validity period of the Kerberos ticket to be at least 10 minutes shorter than the logrotate period.

The BIND service incorrectly handles errors returned by dynamic databases (from dyndb API). As a consequence, BIND enters a deadlock situation on shutdown under certain circumstances. No workaround is available at the moment. If the deadlock occurs, terminate BIND by running the pkill -9 named command and restart the service manually.

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) might fail to get an IPv4 address assigned after the system is booted. The default time to wait for the link to come up is 5 seconds. To work around this issue, increase this wait time by specifying the LINKDELAY directive in the interface configuration file. For example, add the following line to the /etc/sysconfig/network-scripts/ifcfg-<interface> file:

LINKDELAY=10

In addition, check STP settings on all network switches in the path of the DHCP server as the default STP forward delay is 15 seconds.

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.