Troubleshooting practice questions

An administrator is troubleshooting a BIG-IP device that is not responding to configuration changes made via the GUI. The administrator suspects that a control plane service is not running properly. Which two control plane services should the administrator check to ensure that the GUI and configuration management are operational? (Choose two.)

Trap 1: bigd

bigd is the BIG-IP daemon responsible for health monitoring. It is a control plane service but does not manage the GUI or configuration changes. Its failure would impact health checks and load balancing decisions, not the GUI's responsiveness.

Trap 2: tmm

tmm (Traffic Management Microkernel) is a data plane service responsible for processing traffic. While it is essential for traffic handling, it does not directly affect GUI or configuration management. Troubleshooting tmm would be relevant for traffic issues, not control plane responsiveness.

Trap 3: named

named is the DNS service, which is part of the control plane but not directly involved in GUI or configuration management. It handles DNS resolution for the BIG-IP system. Its failure would affect DNS-related features, not the ability to make configuration changes.

A
mcpd
The mcpd (Master Control Program daemon) is the core configuration management daemon. It processes configuration changes from various interfaces (GUI, tmsh, iControl) and applies them to the system. If mcpd is down, configuration changes will not be processed, and the GUI may appear unresponsive. It is a critical control plane service.
B
httpd
The httpd service provides the web-based GUI and iControl REST interface. If httpd is not running, the administrator cannot access the GUI or make configuration changes through it. Checking httpd status is essential for GUI functionality. It is a control plane service managed by tmsh.
C
bigd
Why it fails: bigd is the BIG-IP daemon responsible for health monitoring. It is a control plane service but does not manage the GUI or configuration changes. Its failure would impact health checks and load balancing decisions, not the GUI's responsiveness.
D
tmm
Why it fails: tmm (Traffic Management Microkernel) is a data plane service responsible for processing traffic. While it is essential for traffic handling, it does not directly affect GUI or configuration management. Troubleshooting tmm would be relevant for traffic issues, not control plane responsiveness.
E
named
Why it fails: named is the DNS service, which is part of the control plane but not directly involved in GUI or configuration management. It handles DNS resolution for the BIG-IP system. Its failure would affect DNS-related features, not the ability to make configuration changes.

Question 2mediummulti select

Which TWO of the following tasks are performed by the BIG-IP control plane rather than the data plane?

Trap 1: Processing SSL handshakes for high-volume application traffic.

SSL handshakes for application traffic are processed by TMM to ensure performance and hardware acceleration. Processing these in the control plane would lead to significant performance bottlenecks and would not be able to handle the high throughput requirements typical of production traffic environments and modern web applications.

Trap 2: Executing iRules for Layer 7 load balancing decisions.

iRules are compiled and executed within TMM to facilitate high-speed decision-making for traffic flows. Executing these in the control plane would be inefficient and would introduce latency into every packet or connection request, rendering the BIG-IP system unsuitable for modern, high-performance application delivery requirements and enterprise traffic loads.

Trap 3: Forwarding packets based on the virtual server routing table.

Packet forwarding is the primary responsibility of TMM, the data plane. The control plane does not participate in packet-by-packet forwarding or routing decisions for data plane traffic, as this would violate the core design principle of separating administrative control from high-speed application traffic processing and data transit.

A
Processing SSL handshakes for high-volume application traffic.
Why it fails: SSL handshakes for application traffic are processed by TMM to ensure performance and hardware acceleration. Processing these in the control plane would lead to significant performance bottlenecks and would not be able to handle the high throughput requirements typical of production traffic environments and modern web applications.
B
Synchronizing configuration changes between high-availability peers.
Config sync is a control plane operation that uses the management network to push configuration files between high-availability peers. This task requires high-level coordination of the configuration database, which is inherently a control plane function, ensuring consistency across devices in a device group or administrative cluster.
C
Executing iRules for Layer 7 load balancing decisions.
Why it fails: iRules are compiled and executed within TMM to facilitate high-speed decision-making for traffic flows. Executing these in the control plane would be inefficient and would introduce latency into every packet or connection request, rendering the BIG-IP system unsuitable for modern, high-performance application delivery requirements and enterprise traffic loads.
D
Managing user accounts and administrative access privileges.
User management, including local account creation, LDAP integration, and RBAC assignment, is a core control plane function. These tasks involve interacting with the system's security database and authentication modules, which reside outside the scope of TMM and are managed by the underlying Linux operating system and control plane services.
E
Forwarding packets based on the virtual server routing table.
Why it fails: Packet forwarding is the primary responsibility of TMM, the data plane. The control plane does not participate in packet-by-packet forwarding or routing decisions for data plane traffic, as this would violate the core design principle of separating administrative control from high-speed application traffic processing and data transit.

Question 3mediummultiple choice

When managing multiple BIG-IP devices, why is it recommended to use a centralized NTP server for all devices?

Trap 1: To increase the throughput of the BIG-IP system.

NTP synchronization is a management-plane task that has no impact on the performance of the TMM or the overall data plane throughput. It is strictly for maintaining accurate system time for logs and security protocols, and it does not affect the device's traffic-processing capabilities in any way.

Trap 2: To reduce the CPU utilization of the management plane.

NTP synchronization itself consumes a negligible amount of CPU. While it's a best practice, its primary purpose is not to save CPU cycles but to maintain time accuracy. The impact on control plane CPU usage is insignificant compared to other tasks like logging or API management.

Trap 3: To automate the software upgrade process across devices.

NTP has nothing to do with software upgrades, which are handled through separate image-management processes. While upgrades should be synchronized across HA pairs for consistency, NTP only provides the time reference and does not facilitate the actual transfer or installation of software packages on the BIG-IP.

A
To increase the throughput of the BIG-IP system.
Why it fails: NTP synchronization is a management-plane task that has no impact on the performance of the TMM or the overall data plane throughput. It is strictly for maintaining accurate system time for logs and security protocols, and it does not affect the device's traffic-processing capabilities in any way.
B
To ensure accurate log correlation and certificate validity.
Accurate time is essential for correlating logs from multiple devices during troubleshooting. Additionally, SSL and authentication processes rely on valid timestamps for certificate validation. Using a centralized NTP server ensures all devices have consistent time, which is critical for security and effective operational management of the entire infrastructure.
C
To reduce the CPU utilization of the management plane.
Why it fails: NTP synchronization itself consumes a negligible amount of CPU. While it's a best practice, its primary purpose is not to save CPU cycles but to maintain time accuracy. The impact on control plane CPU usage is insignificant compared to other tasks like logging or API management.
D
To automate the software upgrade process across devices.
Why it fails: NTP has nothing to do with software upgrades, which are handled through separate image-management processes. While upgrades should be synchronized across HA pairs for consistency, NTP only provides the time reference and does not facilitate the actual transfer or installation of software packages on the BIG-IP.

Question 4hardmultiple choice

Refer to the exhibit. Why is it important for the administrator to review the 'show sys hardware' output when troubleshooting a control plane issue?

Exhibit

tmsh show sys hardware
... 
Platform: BIG-IP iSeries i5800
... 
Management IP: 10.0.0.5
... 
CPU: 8 cores
...

Trap 1: It displays the current traffic throughput of all virtual servers.

The 'show sys hardware' command provides information about physical components, such as CPU, memory, and fans. It does not provide traffic throughput statistics for virtual servers. Traffic statistics are found in the 'tmsh show ltm virtual' output, making this option irrelevant to the information provided by the hardware command.

Trap 2: It lists the active users currently logged into the device.

Hardware output shows physical system information, not active user sessions. To see active users, an administrator should use commands like 'who' or check the system logs. Including user session data in the hardware output would be inconsistent with the command's purpose of displaying physical system specifications and component status.

Trap 3: It is required to update the system's licensing information.

Licensing information is handled via the 'tmsh show sys license' command and the F5 license activation server, not through hardware status commands. The 'show sys hardware' command is strictly for platform information and does not interact with the licensing system or trigger license state changes on the appliance.

A
It displays the current traffic throughput of all virtual servers.
Why it fails: The 'show sys hardware' command provides information about physical components, such as CPU, memory, and fans. It does not provide traffic throughput statistics for virtual servers. Traffic statistics are found in the 'tmsh show ltm virtual' output, making this option irrelevant to the information provided by the hardware command.
B
It verifies that the control plane has access to sufficient physical resources.
Understanding the platform's hardware capabilities helps an administrator correlate performance issues with physical resource limits. If the hardware is underpowered for the current configuration, it can cause control plane bottlenecks. This check is a fundamental step in eliminating hardware failure as a root cause for management plane latency.
C
It lists the active users currently logged into the device.
Why it fails: Hardware output shows physical system information, not active user sessions. To see active users, an administrator should use commands like 'who' or check the system logs. Including user session data in the hardware output would be inconsistent with the command's purpose of displaying physical system specifications and component status.
D
It is required to update the system's licensing information.
Why it fails: Licensing information is handled via the 'tmsh show sys license' command and the F5 license activation server, not through hardware status commands. The 'show sys hardware' command is strictly for platform information and does not interact with the licensing system or trigger license state changes on the appliance.

Question 5mediummultiple choice

Which log file is most useful for troubleshooting administrative login attempts and authentication failures on the BIG-IP control plane?

Trap 1: /var/log/ltm

The /var/log/ltm file tracks Local Traffic Manager events, such as virtual server availability, pool member status, and iRule execution. It does not contain administrative login information, making it the wrong place to look when diagnosing issues related to user authentication or management access to the system.

Trap 2: /var/log/messages

The /var/log/messages file acts as a general-purpose log for system-wide notices and error messages. While it may contain some high-level system information, it is not the designated file for specific authentication events, which are separated into the /var/log/secure file for clearer auditing and security management purposes.

Trap 3: /var/log/audit

The /var/log/audit log file is used for recording specific administrative commands executed via tmsh or the GUI when audit logging is enabled. It tracks changes to the configuration, but it is not the primary location for capturing login attempts or failed authentication events for user accounts.

A
/var/log/ltm
Why it fails: The /var/log/ltm file tracks Local Traffic Manager events, such as virtual server availability, pool member status, and iRule execution. It does not contain administrative login information, making it the wrong place to look when diagnosing issues related to user authentication or management access to the system.
B
/var/log/secure
The /var/log/secure file records authentication-related activities on the Linux system, including SSH logins and administrative authentication successes or failures. This is the primary log to check for investigating unauthorized access attempts or troubleshooting why a specific administrator cannot log in to the system via the management interface.
C
/var/log/messages
Why it fails: The /var/log/messages file acts as a general-purpose log for system-wide notices and error messages. While it may contain some high-level system information, it is not the designated file for specific authentication events, which are separated into the /var/log/secure file for clearer auditing and security management purposes.
D
/var/log/audit
Why it fails: The /var/log/audit log file is used for recording specific administrative commands executed via tmsh or the GUI when audit logging is enabled. It tracks changes to the configuration, but it is not the primary location for capturing login attempts or failed authentication events for user accounts.

Question 6hardmultiple choice

An administrator is unable to access the GUI, but SSH access is still functioning. What is the most appropriate next step for diagnosing the issue?

Trap 1: Reboot the entire BIG-IP system.

Rebooting should be the last resort, as it is disruptive and does not help identify the root cause of the issue. The administrator should first attempt to diagnose and restart the specific service that is failing, which is faster and maintains system availability for the traffic-processing TMM.

Trap 2: Fail over the BIG-IP unit immediately.

Failover is a drastic measure that should only be taken if the service cannot be recovered and the device is currently failing to process traffic. Since only the GUI is affected, failing over would be an unnecessary disruption that does not address the underlying issue with the web service.

Trap 3: Re-license the BIG-IP device.

A GUI failure is rarely related to licensing. If the license were invalid, the system would typically provide clear error messages regarding the license status rather than just failing to load the GUI. Re-licensing would not fix a service-level failure, making it an inappropriate step for this specific symptom.

A
Reboot the entire BIG-IP system.
Why it fails: Rebooting should be the last resort, as it is disruptive and does not help identify the root cause of the issue. The administrator should first attempt to diagnose and restart the specific service that is failing, which is faster and maintains system availability for the traffic-processing TMM.
B
Check the status of the httpd service using tmsh.
The httpd service provides the web-based GUI. If the GUI is down but SSH is up, the httpd service has likely crashed or hung. Checking its status via the CLI is the proper diagnostic step to determine if it needs to be restarted, restoring GUI access without affecting traffic.
C
Fail over the BIG-IP unit immediately.
Why it fails: Failover is a drastic measure that should only be taken if the service cannot be recovered and the device is currently failing to process traffic. Since only the GUI is affected, failing over would be an unnecessary disruption that does not address the underlying issue with the web service.
D
Re-license the BIG-IP device.
Why it fails: A GUI failure is rarely related to licensing. If the license were invalid, the system would typically provide clear error messages regarding the license status rather than just failing to load the GUI. Re-licensing would not fix a service-level failure, making it an inappropriate step for this specific symptom.

Question 7mediummultiple choice

Refer to the exhibit. An administrator is troubleshooting a failed configuration sync. The log shows a bad argument error related to the management IP. What is the most likely cause?

Exhibit

Sys::Config::Log
Level: Warning
Output: Local0
Rotation: Daily
Status: Active

Error: [01070712:3] Caught exception: Bad Argument: 10.10.1.50 (Management IP).

Trap 1: The TMM process has crashed on the peer.

A TMM crash would typically result in a complete loss of traffic processing, not a specific bad argument error related to a management IP address. The error log specifically points to a configuration argument issue, suggesting a misconfiguration in the high-availability (HA) settings rather than a process failure.

Trap 2: The license on the peer has expired.

License expiration typically generates specific system alerts or prevents the TMM process from starting. It does not manifest as a 'Bad Argument' error during the execution of a configuration sync command. The error specifically references the management IP address, pointing to a networking or sync configuration problem.

Trap 3: The NTP server is unreachable.

While clock synchronization is critical for HA, an unreachable NTP server would trigger specific time-sync warnings, not a bad argument error related to the management IP address during a sync operation. These issues are distinct and would be logged in the system log with different error codes.

A
The TMM process has crashed on the peer.
Why it fails: A TMM crash would typically result in a complete loss of traffic processing, not a specific bad argument error related to a management IP address. The error log specifically points to a configuration argument issue, suggesting a misconfiguration in the high-availability (HA) settings rather than a process failure.
B
The peer management IP is not reachable for ConfigSync.
ConfigSync requires reliable reachability between peer management IP addresses. The bad argument error often suggests the system cannot resolve or reach the defined peer management interface, indicating that the sync configuration contains an incorrect IP or a network path issue preventing the synchronization of configuration objects.
C
The license on the peer has expired.
Why it fails: License expiration typically generates specific system alerts or prevents the TMM process from starting. It does not manifest as a 'Bad Argument' error during the execution of a configuration sync command. The error specifically references the management IP address, pointing to a networking or sync configuration problem.
D
The NTP server is unreachable.
Why it fails: While clock synchronization is critical for HA, an unreachable NTP server would trigger specific time-sync warnings, not a bad argument error related to the management IP address during a sync operation. These issues are distinct and would be logged in the system log with different error codes.

Question 8hardmultiple choice

An administrator is troubleshooting a BIG-IP device that is failing to synchronize configuration changes with its peer. The administrator runs 'tmsh show cm sync-status' and sees 'Changes Pending'. Which action should the administrator take first to identify the cause?

Trap 1: Run 'tmsh show sys mcp-state' to verify the mcpd daemon is running.

While mcpd is essential for configuration management, if it were not running, the device would likely be in a different state and 'show cm sync-status' would not return 'Changes Pending'. The issue is specifically about synchronization between peers, so verifying the daemon state is less directly relevant than checking device trust and group membership.

Trap 2: Run 'tmsh show cm sync-status' with the 'verbose' option to see…

The 'verbose' option may provide more detail, but it is not the first step. The 'Changes Pending' status indicates that there are unsynchronized changes, but the root cause could be a trust issue or device group misconfiguration. Checking device trust and group status is a more fundamental first step to rule out communication problems.

Trap 3: Run 'tmsh show sys config' to compare the running configuration…

This command shows the current running configuration but does not directly help with synchronization between peers. The issue is not about running vs. saved config on this device, but about why changes are not being synchronized to the peer. Comparing configurations manually is inefficient and does not address trust or device group issues.

A
Run 'tmsh show sys mcp-state' to verify the mcpd daemon is running.
Why it fails: While mcpd is essential for configuration management, if it were not running, the device would likely be in a different state and 'show cm sync-status' would not return 'Changes Pending'. The issue is specifically about synchronization between peers, so verifying the daemon state is less directly relevant than checking device trust and group membership.
B
Run 'tmsh show cm device' to check the device group and trust status.
This command displays the device's synchronization state, trust status, and device group membership. If the device is not trusted or not in the correct device group, synchronization will fail. Checking this first is logical because it verifies the foundational communication and group configuration before diving deeper into specific configuration differences.
C
Run 'tmsh show cm sync-status' with the 'verbose' option to see detailed differences.
Why it fails: The 'verbose' option may provide more detail, but it is not the first step. The 'Changes Pending' status indicates that there are unsynchronized changes, but the root cause could be a trust issue or device group misconfiguration. Checking device trust and group status is a more fundamental first step to rule out communication problems.
D
Run 'tmsh show sys config' to compare the running configuration with the saved configuration.
Why it fails: This command shows the current running configuration but does not directly help with synchronization between peers. The issue is not about running vs. saved config on this device, but about why changes are not being synchronized to the peer. Comparing configurations manually is inefficient and does not address trust or device group issues.

Question 9easymultiple choice

An administrator is troubleshooting an issue where changes made through the BIG-IP Configuration utility (GUI) are not appearing in the tmsh configuration. The administrator suspects that the GUI and tmsh are using different configuration sources. Which statement correctly describes how the GUI and tmsh interact with the BIG-IP configuration?

Trap 1: The GUI uses a proprietary protocol to communicate with the…

The GUI does not use a proprietary protocol; it uses HTTPS to communicate with the web server, which then interacts with mcpd. tmsh does not use SNMP for configuration; it uses a local socket to communicate with mcpd. SNMP is used for monitoring and some management, but not for configuration changes via tmsh.

Trap 2: The GUI writes directly to the bigip.conf file, while tmsh reads…

The GUI does not write directly to the bigip.conf file. Both the GUI and tmsh interact with the configuration through the mcpd daemon, which manages the configuration database. Direct file editing is discouraged and can lead to inconsistencies. The GUI and tmsh both use the same underlying configuration system.

Trap 3: tmsh reads the configuration from the bigip.conf file every time a…

tmsh does not read the bigip.conf file for every command. It interacts with the mcpd daemon, which holds the current configuration in memory and writes to disk when changes are saved. The GUI also interacts with mcpd and does not simply cache settings independently. Both interfaces rely on mcpd for the authoritative configuration state.

A
The GUI uses a proprietary protocol to communicate with the configuration, while tmsh uses SNMP.
Why it fails: The GUI does not use a proprietary protocol; it uses HTTPS to communicate with the web server, which then interacts with mcpd. tmsh does not use SNMP for configuration; it uses a local socket to communicate with mcpd. SNMP is used for monitoring and some management, but not for configuration changes via tmsh.
B
Both the GUI and tmsh modify the configuration through the mcpd daemon, which updates the configuration files.
The GUI and tmsh both communicate with the mcpd (Master Control Program daemon) to make configuration changes. The mcpd daemon is responsible for managing the configuration database and writing changes to the appropriate configuration files, such as /config/bigip.conf. This ensures consistency between the GUI and tmsh. Therefore, changes made in the GUI should be visible in tmsh after they are committed.
C
The GUI writes directly to the bigip.conf file, while tmsh reads from a separate database.
Why it fails: The GUI does not write directly to the bigip.conf file. Both the GUI and tmsh interact with the configuration through the mcpd daemon, which manages the configuration database. Direct file editing is discouraged and can lead to inconsistencies. The GUI and tmsh both use the same underlying configuration system.
D
tmsh reads the configuration from the bigip.conf file every time a command is entered, while the GUI caches settings in memory.
Why it fails: tmsh does not read the bigip.conf file for every command. It interacts with the mcpd daemon, which holds the current configuration in memory and writes to disk when changes are saved. The GUI also interacts with mcpd and does not simply cache settings independently. Both interfaces rely on mcpd for the authoritative configuration state.

Question 10easymultiple choice

Which file path contains the primary BIG-IP configuration file that the mcpd daemon loads at startup?

Trap 1: /var/tmp/bigip.conf

/var/tmp is a temporary directory for scratch files and is not used for storing production configuration. Any changes made to a file in this location would not be recognized by the mcpd daemon, and the system would revert to the default configuration on boot, resulting in a loss of settings.

Trap 2: /etc/bigip.conf

/etc is reserved for standard Linux system configuration files. BIG-IP specific configuration resides in the /config directory structure, which is maintained by the F5 operating system. Using /etc for BIG-IP configuration would result in the system ignoring the file entirely, as the mcpd daemon looks specifically in the /config path.

Trap 3: /var/lib/bigip.conf

/var/lib is generally used for persistent application data in Linux, not for the primary BIG-IP configuration. The mcpd daemon is hardcoded to look for the configuration file in the /config directory. Files placed in /var/lib will not be loaded, meaning any configuration changes made there will be completely ineffective.

A
/var/tmp/bigip.conf
Why it fails: /var/tmp is a temporary directory for scratch files and is not used for storing production configuration. Any changes made to a file in this location would not be recognized by the mcpd daemon, and the system would revert to the default configuration on boot, resulting in a loss of settings.
B
/etc/bigip.conf
Why it fails: /etc is reserved for standard Linux system configuration files. BIG-IP specific configuration resides in the /config directory structure, which is maintained by the F5 operating system. Using /etc for BIG-IP configuration would result in the system ignoring the file entirely, as the mcpd daemon looks specifically in the /config path.
C
/config/bigip.conf
/config/bigip.conf is the definitive location for the main BIG-IP configuration. The mcpd daemon reads this file upon startup to populate the system's memory-based configuration database. This path is essential for all administrative configuration tasks and is the primary file that administrators interact with when performing manual configuration management or backups.
D
/var/lib/bigip.conf
Why it fails: /var/lib is generally used for persistent application data in Linux, not for the primary BIG-IP configuration. The mcpd daemon is hardcoded to look for the configuration file in the /config directory. Files placed in /var/lib will not be loaded, meaning any configuration changes made there will be completely ineffective.

Question 11easymultiple choice

Which utility should an administrator use to monitor real-time resource consumption on the BIG-IP control plane, specifically for identifying processes consuming high CPU?

Trap 1: tmsh show sys performance

This command displays historical traffic and throughput statistics for the TMM. While useful for monitoring data plane performance, it does not provide the process-level details or Linux-specific resource utilization data required to troubleshoot control plane CPU spikes caused by local processes on the management system.

Trap 2: bigtop

The bigtop command is designed to show traffic management statistics related to virtual servers, pools, and connections. It focuses on the TMM (Traffic Management Microkernel) performance rather than the Linux-based control plane processes, making it unsuitable for identifying specific CPU-intensive management tasks on the system.

Trap 3: tmsh show sys connection

This command provides details on active network connections passing through the BIG-IP. It is intended for tracking client-to-server traffic flows and does not provide any visibility into the control plane's internal process utilization, CPU metrics, or memory consumption of the system's management services.

A
tmsh show sys performance
Why it fails: This command displays historical traffic and throughput statistics for the TMM. While useful for monitoring data plane performance, it does not provide the process-level details or Linux-specific resource utilization data required to troubleshoot control plane CPU spikes caused by local processes on the management system.
B
top
The top utility provides a real-time, dynamic view of running system processes, including CPU and memory usage per process. It is the most effective command for diagnosing which specific management-plane processes are causing high system load, ensuring the administrator can identify and remediate the underlying issue.
C
bigtop
Why it fails: The bigtop command is designed to show traffic management statistics related to virtual servers, pools, and connections. It focuses on the TMM (Traffic Management Microkernel) performance rather than the Linux-based control plane processes, making it unsuitable for identifying specific CPU-intensive management tasks on the system.
D
tmsh show sys connection
Why it fails: This command provides details on active network connections passing through the BIG-IP. It is intended for tracking client-to-server traffic flows and does not provide any visibility into the control plane's internal process utilization, CPU metrics, or memory consumption of the system's management services.