201 Sample Questions & Answers

In the BIG-IP Network Map, different shapes and colors represent the status of objects. A blue square specifically indicates that the object (in this case, a pool member) is available but its health status is unknown because there is no health monitor assigned to it. The system cannot verify its ability to service requests.

The standard, best-practice procedure for upgrading an HA pair is to perform the operation on the standby unit first. This allows the active unit to continue handling traffic. Once the standby unit is successfully upgraded and rebooted into the new software version, the administrator can force a failover. The newly upgraded unit becomes active, and the process is repeated on the other unit, which is now the standby. This ensures traffic is always being handled by one of the units.

Setting a pool member's state to 'Disabled' is the correct action for graceful removal. This state allows existing connections, including those maintained by persistence, to continue until they are closed or time out. However, it prevents the BIG-IP from sending any new connections to that member. 'Forced Offline', in contrast, marks the member as down and immediately stops it from receiving any traffic, which could disrupt existing user sessions.

The BIG-IP system checks for a persistence record before making a load balancing decision. If a client has an existing persistence record for a specific pool member, the system will send the new connection to that member, regardless of the 'Least Connections' algorithm. If most returning clients are persisted to other members, a new or underutilized member will receive very little traffic.

The 'Guest' role in TMOS is specifically designed for read-only access. Users with this role can log in to the Configuration Utility and view configurations, statistics, and statuses, but they are prohibited from making any changes. This is the principle of least privilege in action for monitoring purposes.

If the monitor timeout is shorter than the server's typical response time, the monitor will frequently fail, marking the member down. When the server does respond within the interval, it will be marked up again, leading to a flapping state.

Health monitor probes are network packets. If there is intermittent packet loss or high latency on the path between the BIG-IP and the server, some monitor probes will fail while others succeed, causing the member's status to flap between up and down.

On a BIG-IP system, being licensed for a module is not enough to use it. An administrator must also provision system resources (CPU, memory) to it. This is done in the System > Resource Provisioning section of the Configuration Utility. After provisioning, the relevant daemons are started and the configuration options appear in the GUI.

A UCS archive is a comprehensive backup of a BIG-IP system's critical data. By default, it includes all configuration files (like bigip.conf), the system license file, and all locally stored SSL certificates and private keys. This makes it a complete, self-contained backup for system restoration.

This configuration meets all requirements. 1) The Standard VS listens on 172.16.100.50:443. 2) The Client SSL profile terminates the client-side HTTPS. 3) The HTTP profile allows L7 inspection, and the pool members are set to port 8080. 4) SNAT Automap is crucial because the servers lack a return route; it forces all server-side traffic to originate from the egress self-IP (10.10.10.5). 5) The HTTP monitor correctly checks the application on port 8080.

This is a classic asymmetric routing problem. If SNAT is not used, the server sees the client's real IP and tries to respond directly to it. The server's SYN-ACK goes out its default gateway, bypassing the BIG-IP. The BIG-IP, having never received the SYN-ACK it was expecting from the server, cannot complete the three-way handshake with the client. The solution is typically to enable SNAT on the virtual server.