An LTM Specialist configures two LTM devices in a high-availability pair with trusts established and device
groups configured properly using network failover. After several months, the LTM Specialist notices that
changes made to one LTM device do NOT cause the synchronization status to update to “changes
pending,” and this device does NOT synchronize with the device group.

Which two steps should the LTM Specialist take to identify the issue? (Choose two.)

An LTM Specialist is troubleshooting an issue where one LTM device in a three LTM device group is failing
to synchronize after a synchronize to group command is issued. The LTM Specialist verifies there are no
packet filters, port lock down, or network issues preventing the connection.
What are two reasons the synchronization group is having issues? (Choose two.)

An LTM Specialist has just manually failed the active LTM device over to the standby LTM device. The LTM
Specialist notices the newly active LTM device is NOT currently receiving traffic. The LTM Specialist verifies
the newly active device is responding to ARP but still no traffic is hitting the virtual servers. The LTM
Specialist also notices that the virtual servers eventually start responding.What should be added to the configuration to resolve the problem?

A failover event is recorded in the log messages:
Jan 01 00:00:50 BIG-IP notice sod[5855]: 01140029:5: HA proc_running tmm fails action is go offline and
down links.
Jan 01 00:00:50 BIG-IP notice sod[5855]: 010c0050:5: Sod requests links down.
Jan 01 00:00:50 BIG-IP notice sod[5855]: 010c0054:5: Offline for traffic group /Common/traffic-group-1.
Jan 01 00:00:50 BIG-IP notice sod[5855]: 010c003e:5: Offline
Jan 01 00:00:50 BIG-IP notice logger: /usr/bin/tmipsecd –tmmcount 4 ==> /usr/bin/bigstart stop racoon
Jan 01 00:00:50 BIG-IP info lacpd[5502]: 01160016:6: Failover event detected. (Switchboard failsafe
disabled while offline)
Jan 01 00:00:51 BIG-IP err bcm56xxd[5296]: 012c0010:3: Failover event detected. Marking external
interfaces down. bsx.c(3633)
Jan 01 00:00:51 BIG-IP info bcm56xxd[5296]: 012c0015:6: Link: 1.1 is DOWN
Jan 01 00:00:56 BIG-IP notice mcpd[5318]: 0107143c:5: Connection to CMI peer 10.0.0.3 has been
removed
Jan 01 00:00:56 BIG-IP notice mcpd[5318]: 0107143a:5: CMI reconnect timer: enabled
Jan 01 00:00:56 BIG-IP notice mcpd[5318]: 01071431:5: Attempting to connect to CMI peer 10.0.0.3 port
6699
What is the cause of the failover?

While investigating the cause of a device failover, an LTM Specialist discovers the following events in /var/
log/ltm:
01010029:5: Clock advanced by 518 ticks01010029:5: Clock advanced by 505 ticks
01010029:5: Clock advanced by 590 ticks
01010029:5: Clock advanced by 568 ticks
01010029:5: Clock advanced by 1681 ticks
01010029:5: Clock advanced by 6584 ticks
01140029:5: HA daemon_heartbeat tmm fails action is failover and restart.
010c0026:5: Failover condition, active attempting to go standby.
Which issue caused the failover?

A high-availability (HA) pair configuration uses only the hardwire serial cable connection to determine
device state. A power outage occurs to the PDU powering the active unit. The standby unit takes over the
active role as expected.
How is the peer unit able to determine the active unit is unavailable?

In preparation for a maintenance task, an LTM Specialist performs a “Force to Standby” on LTM device
Unit 1. LTM device Unit 2 becomes active as expected. The maintenance task requires the reboot of Unit 1.
Shortly after the reboot is complete, the LTM Specialist discovers that Unit 1 has become active and Unit 2
has returned to standby.
What would cause this behavior?

Given LTM device ltm log:
Sep 26 20:51:08 local/lb-d-1 notice promptstatusd[3695]: 01460006:5: semaphore mcpd.running(1) held
Sep 26 20:51:08 local/lb-d-1 notice promptstatusd[3695]: 01460006:5:
Sep 26 20:51:08 local/lb-d-1 warning promptstatusd[3695]: 01460005:4: mcpd.running(1) held, wait for
mcpd
Sep 26 20:51:08 local/lb-d-1 info sod[3925]: 010c0009:6: Lost connection to mcpd – reestablishing.
Sep 26 20:51:08 local/lb-d-1 err bcm56xxd[3847]: 012c0004:3: Lost connection with MCP: 16908291 …
Exiting bsx_connect.cpp(174)
Sep 26 20:51:08 local/lb-d-1 info bcm56xxd[3847]: 012c0012:6: MCP Exit Status
Sep 26 20:51:08 local/lb-d-1 info bcm56xxd[3847]: 012c0012:6: Info: LACP stats (time now:1348717868) :
no traffic
Sep 26 20:51:08 local/lb-d-1 info bcm56xxd[3847]: 012c0014:6: Exiting…
Sep 26 20:51:08 local/lb-d-1 err lind[3842]: 013c0004:3: IO error on recv from mcpd – connection lost
Sep 26 20:51:08 local/lb-d-1 notice bigd[3837]: 01060110:5: Lost connection to mcpd with error 16908291,
will reinit connection.
Sep 26 20:51:08 local/lb-d-1 err statsd[3857]: 011b0004:3: Initial subscription for system configuration failed
with error ”
Sep 26 20:51:08 local/lb-d-1 err statsd[3857]: 011b0001:3: Connection to mcpd failed with error
‘011b0004:3: Initial subscription for system configuration failed with error ”’
Sep 26 20:51:08 local/lb-d-1 err csyncd[3851]: 013b0004:3: IO error on recv from mcpd – connection lost
………….skipping more logs…..
Sep 26 20:51:30 local/lb-d-1 notice sod[3925]: 01140030:5: HA proc_running bcm56xxd is now responding.
Sep 26 20:51:34 local/lb-d-1 notice sod[3925]: 01140030:5: HA proc_running mcpd is now responding.
Sep 26 20:51:34 local/lb-d-1 notice sod[3925]: 010c0018:5: StandbyWhich daemon failed?

An active/standby pair of LTM devices deployed with network failover are working as desired. After external
personnel perform maintenance on the network, the LTM devices are active/active rather than active/
standby. No changes were made on the LTM devices during the network maintenance.
Which two actions would help determine the cause of the malfunction? (Choose two.)

The active LTM device in a high-availability (HA) pair performs a failover at the same time the network team
reports an outage of a switch on the network.Which two items could have caused the failover event? (Choose two.)