Applies To:Show Versions
BIG-IP Edge Gateway
Troubleshooting BIG-IP Virtual Edition
If you have followed the setup procedures as described in this guide, BIG-IP VE should be working correctly with the hypervisor. However, because BIG-IP VE emulates BIG-IP hardware running in a virtual environment, you might encounter some issues as you try new configurations for BIG-IP VE that are outside the scope of this setup guide, or unsupported in BIG-IP VE with certain hypervisor environments. Use this troubleshooting information to solve problems and address limitations that you might encounter with BIG-IP VE.
- Event log reports insufficient video RAM
- On VMware ESXi systems only, the following event message is logged: The maximum resolution of the virtual machine will be limited to 1176x885 at 16 bits per pixel. To use the configured maximum resolution of 2360x1770 at 16 bits per pixel, increase the amount of video RAM allocated to this virtual machine by setting svga.vramSize="16708800" in the virtual machine's configuration file. You can ignore this message or follow the recommended action without adverse effects.
- Time synchronization using VMware Tools or NTP protocol
- If you want to use VMware Tools to enable time synchronization, you must select the Synchronize guest time with host check box within vSphere Client. If you want to use network time protocol (NTP) instead, you must first disable time synchronization in VMware Tools by clearing the check box within vSphere Client. For more information, see the VMware vSphere Client documentation. Note that the two units of a BIG-IP VE redundant system configuration must share the same time synchronization source.
- Incorrect status of VMware Tools in vSphere
- VMware vSphere incorrectly shows the status of VMware Tools as Not Installed. You can verify that VMware Tools are installed by viewing the IP Address and DNS Name fields on the vSphere screen. Note that if you migrate the virtual machine or start a snapshot or cloned image of the virtual machine, the status correctly shows as Unmanaged.
- Lack of VMXNET3 availability
- The VMXNET3 driver can become unavailable after you suspend and resume BIG-IP VE. Resetting the BIG-IP VE will resolve the problem.
- Use of VLAN groups
- Use of VLAN groups with BIG-IP VE requires proper configuration of the VMware vSwitch. To use the VLAN group feature, you must configure security policies on the vSwitch. The properties of the security policy that you need to configure are Promiscuous Mode and Forged Transmits. For any transparency mode, you must configure these properties to accept (rather than reject) the security policy exceptions on the vSwitch. For information about how to configure these options, see the VMware ESX® or ESXi® Configuration Guide.
- Use of Single Configuration File (SCF) feature
- Copying an SCF from a VMware host system to an F5 hardware platform causes an error related to interface mismatching. Edit the SCF and remove speed and duplex media statements from the network interface statements before importing.
- Configuration of an OVF with additional interfaces
When you deploy an OVF with more than five interfaces (one management interface and more than four TMM interfaces), the interface numbering might appear out of order. To view the actual TMM-to-vSwitch portgroup interface mapping, compare the MAC addresses of the interfaces displayed in the BIG-IP Configuration utility to those displayed in the vSphere Client.
If you change the number of virtual interfaces on the BIG-IP VE system after a binary MCPD database has been created, the system does not detect the change when subsequently rebooted. To ensure that the system properly detects the new or removed interfaces, type the command rm /var/db/mcpd* at the BIG-IP VE command prompt, and reboot the system.
- HA events due to BIG-IP VE inactivity
- If the VMware hypervisor runs the BIG-IP VE software for fewer than four minutes continuously (for example, due to a manual suspension or the timeout of network disk I/O), high-availability failure events occur. The system might note a failure and restart key system processes and trigger failover if within a high-availability (HA) group. This is intended system behavior.
- VMware vSwitch Promiscuous Mode
- When the VMware vSwitch Promiscuous Mode is set to Reject, the VLAN group transparency mode, Opaque, will not be able to pass packets.
- Virtual network interface status is wrong
- The BIG-IP VE system reports the status of host-only network interfaces as UNINITIALIZED, even though the interface is functioning normally.
- Auto-licensing and the default management route
- If you have not defined a default route to the management port, the default interface 1.1 is used, which does not work. To prevent this from occurring, verify that you have defined a default route for the management port before attempting to activate a license.
- BIG-IP licensing and User Configuration Sets
- When you import a User Configuration Set (UCS) from another BIG-IP system or BIG-IP VE system, the system overwrites the local license with the license contained in the UCS. To work around this issue, you can re-license the local system after importing the UCS by accessing a backup copy of the license file, located in /config/bigip.license.bak. Also, when importing a UCS, ensure that the host names of the two systems differ. When the host names differ, the system correctly imports only the configuration data that is common to both the originating platform and the target platform. If the host names match, the system attempts to import all of the UCS configuration data, which can cause the import process to fail.
- Use of SNMP OID for RMON tables
- Setting the source OID for RMON alarm, event, and history tables generates an error message. This OID will be disabled in future releases.
- Media speed messages in log file
- When starting the BIG-IP VE system or when removing an interface from a VLAN, the system logs media-related messages to the file /var/log/ltm. You can ignore these messages.
- The virtual switch clears the QoS field in 802.1q headers
- A hypervisor's Layer 2 bridging device might remove quality of service (QoS) classification from packets.