CCNA Nse4 Ha Diagnostics Questions

ZTNA enables per-application, identity-based access control: the FortiGate acts as an access proxy, authenticating the user (via SAML, LDAP, or local login) and verifying device posture (using FortiClient or other telemetry) before allowing a short-lived, encrypted session to a specific internal application. This eliminates the need for a full VPN tunnel, enforcing least-privilege access while keeping the user unaware of the complete internal network.

Configuring a ZTNA rule with a ZTNA tag requirement is the only option that directly enforces security posture. The FortiGate requires that the connecting client present a specific tag that is only issued after the endpoint passes posture checks such as patching and host firewall status. If the tag is absent or does not match the required value, the rule blocks access. This tag-based enforcement is the core mechanism for zero-trust posture verification in Fortinet's ZTNA.

diagnose sniffer packet is the correct command for real-time packet-level monitoring. It instructs the FortiGate's kernel to capture raw packets on a specified interface (or 'any') and displays their headers and payload directly in the terminal, optionally filtered by protocol, host, or port. This is equivalent to tcpdump on Linux and is the go-to tool when you need to see the actual bytes crossing the wire, not just session summaries.

The most common cause of an HA cluster refusing to form after a firmware upgrade is that FortiGate HA does not support mixed FortiOS versions across cluster members. When one unit runs a newer build than the other, the cluster cannot synchronize because the internal protocol/data structures differ, and the HA status will report a firmware version mismatch. Since the problem appeared right after the upgrade, verifying that both units are on the same upgraded firmware build is the correct first step.

FortiCloud log forwarding is configured under Log Settings, where the administrator must explicitly select which log types (traffic, event, security) are sent to FortiCloud. If only the default or local log types are enabled, or if these categories are left unchecked, the FortiGate will not upload the corresponding logs even though local logging works. This is a common misconfiguration because enabling local logging does not automatically enable cloud forwarding for every log type; each category must be individually selected in the FortiCloud log settings.

Enabling remote logging under Log Settings and specifying the FortiAnalyzer IP address configures the FortiGate to stream logs directly to FortiAnalyzer over the network using its dedicated logging protocols. This is the correct method because it establishes FortiAnalyzer as a log destination, ensuring that traffic logs are continuously transferred to the central analyzer regardless of local disk capacity or local retention policies.

When override is enabled on the cluster, a recovered primary unit with a higher priority will immediately take over as active, preempting the current secondary. The takeover occurs after the cluster re-establishes heartbeat and synchronizes session state, ensuring that traffic convergence is orderly. This preemptive behavior is the defining feature of HA override, and it distinguishes the mode from non-preemptive operation where the current active unit would otherwise remain active.

Enabling session synchronization (session sync) in the HA cluster causes the active FortiGate to continuously replicate its entire session table — including NAT mappings, TCP sequence numbers, and timers — to the standby unit over the heartbeat link. Because the standby now possesses an up-to-date copy of all state, it can immediately assume forwarding during a failover and existing TCP sessions remain intact without client reconnection. Without this feature, no amount of heartbeat, priority, or override tuning can save sessions; this is the only mechanism that directly addresses session preservation.

HA priority is the configurable value (1 to 255, with higher being better) that directly determines which FortiGate unit becomes the active unit in an HA cluster. During the election process, the unit with the highest priority is selected as active; if priorities are equal, other factors like uptime and port monitoring are used as tie-breakers. This is the standard and primary method for controlling the active/standby role in FortiGate HA, making it the correct answer.

Override is an HA election control in FortiGate. When enabled, if a unit with a higher configured priority fails and later recovers, it will preempt the current primary (which may have a lower priority) and reclaim the primary role automatically. This ensures the preferred unit is always active after recovery, but it can cause a brief service interruption. Without override, the recovered higher-priority unit would rejoin the cluster as a secondary and remain so until the active primary fails.

Traffic logs are the FortiGate log type that records every session attempt processed by the firewall, including both permitted and denied traffic. Each traffic log entry contains source and destination addresses, ports, service, action (allow/deny), policy ID, and byte counts, and it is generated from the session table when a session closes or at a configured periodic interval. This is the correct answer because traffic logs are specifically designed to log all session activity.

Syslog is the standard protocol for forwarding system logs from network devices to a centralized log collector. FortiGate supports sending syslog messages to external servers over UDP (default 514), TCP, or TLS, with configurable severity and formats like RFC 3164 or RFC 5424. This makes it the correct choice for delivering FortiGate's full event logs to an external system.

In FortiGate HA, dedicated heartbeat interfaces are mandatory because they carry the Hello packets that allow units to discover each other and elect the active unit. If no heartbeat interface is configured, the FortiGates never exchange any HA traffic, so they remain in standalone mode even if all other HA settings, such as group ID and password, are correctly set. This is the most direct and fundamental cause of the inability to form a cluster.

This command functions like the Linux 'top' utility, presenting a real-time, updating list of FortiOS processes with per-process CPU and memory consumption. It is the correct tool for identifying which specific process is causing high CPU during a performance issue. By observing the process list, an administrator can pinpoint the culprit, such as an overactive log daemon or the antivirus scanning engine, and take targeted action.

Configuring FortiAnalyzer under Log Settings is the correct procedure: in the FortiGate GUI, navigate to Log & Report > Log Config > Log Settings, and add a new FortiAnalyzer entry by specifying its IP address, serial number (optional), and communication settings. This enables the FortiGate to send logs to the FortiAnalyzer using the proprietary FortiAnalyzer protocol, which supports efficient log forwarding, encryption, and integration with FortiAnalyzer's analytics and reporting engines. It is the dedicated method for forwarding logs to a FortiAnalyzer device.

diagnose sniffer packet is the standard FortiGate packet capture tool, analogous to tcpdump or Wireshark. It captures raw packets at the kernel level on specified interfaces or VLANs, displaying actual packet headers and payload in real time. This command is essential for analyzing the exact traffic content, checksums, and any malformed packets, making it the correct choice for troubleshooting traffic flow issues at Layer 2-4.

Emergency is the highest severity level in FortiGate logging, reserved for conditions that render the system unusable or that require immediate administrator intervention, such as a detected power loss, fatal system error, or hardware malfunction. Unlike other levels, Emergency signals an active, often catastrophic failure that demands urgent action to restore service and prevent data loss or security compromise. This directly matches the question's requirement for a failure that necessitates immediate response, making Emergency the correct choice.

The virtual cluster ID is a mandatory HA parameter that must be the same on both units to ensure they belong to the same cluster and can synchronize correctly. This ID is used in heartbeat negotiation and for VDOM partitioning to separate multiple clusters on the same Layer 2 segment. If the virtual cluster IDs differ, the units will not form an HA cluster, even if all other settings are identical.

The heartbeat interface is dedicated to carrying HA heartbeat packets—typically UDP probes—that each cluster member sends and expects to receive. Loss of these heartbeats indicates a peer, link, or interface failure, prompting the primary unit to initiate failover and the backup to take over. Its sole primary purpose is to continuously assess peer liveness and trigger the designated failover logic, not to move user traffic or serve as a management path.

The debug flow message 'No matching interface to route packet' means the FortiGate found no route entry for the destination IP, so the packet cannot be forwarded. The routing table lookup failed, indicating a missing or incorrect route rather than a policy or interface issue.

Configuring two heartbeat interfaces provides redundancy for heartbeat communication. If one heartbeat link fails, the other can still carry heartbeat packets, reducing the risk of split-brain. Enabling heartbeat failover allows the cluster to use the secondary heartbeat interface when the primary fails. This is a recommended practice to maintain cluster integrity and avoid both units becoming primary.

Adding the FortiAnalyzer as a logging device in System > FortiAnalyzer is the correct method because FortiGate communicates with FortiAnalyzer using the FortiAnalyzer protocol—a proprietary, secure connection that registers the FortiGate, handles authentication, and forwards logs to the FortiAnalyzer's dedicated log database. In the FortiAnalyzer settings you specify the FortiAnalyzer IP address, the serial number for registration, and optionally enable SSL encryption; this creates a direct log-forwarding pipeline beyond simple syslog. This integration is the designed path for an external FortiAnalyzer to receive logs, enabling centralized management, advanced search, and reporting.

Disabling HA override on both units is the correct solution because this setting prevents a unit with a higher priority from preempting the current primary as long as that primary is functioning normally. With override disabled, the active primary remains the primary until it actually fails, eliminating the automatic failback event that would otherwise occur when the recovered unit comes online. This ensures stable operation and avoids unnecessary traffic interruption in an active-passive HA deployment.

Enabling session pickup enables FortiOS to continuously replicate the active unit's session table, including NAT mappings and firewall state, to the standby unit over the synchronization link. On failover, the standby unit promotes itself to primary and already has all active sessions queued, enabling established connections to survive without re-handshake. This is the only option that directly addresses the requirement for stateful failover and is the standard way to preserve sessions in an active-passive HA cluster.

In FortiGate's syslog-compatible severity numbering, 4 is exactly Warning, which signals that an abnormal condition has been detected that may require action before a failure occurs. Examples include a VPN tunnel flapping or a security policy denying traffic; these are logged and displayed with the warning icon. Determining that a received log has severity 'warning' therefore maps to the numeric value 4, making this the correct answer.

In an active-active HA cluster, traffic for a single connection can egress and ingress through different members, and each member must have a copy of the session table. Without session synchronization, the secondary unit that receives the response has no record of the session created by the primary, so it treats the packet as unsolicited traffic and drops it. Enabling session synchronization (for example with 'set session-sync-dev' or using session pickup on FortiGate) ensures both units share session state and can forward replies correctly.

In an HA cluster, all interface and link aggregation group (LAG) settings—including member ports, negotiation mode, and hashing algorithm—must be identical across both units. If the replacement FortiGate's LAG configuration differs from the active cluster configuration, the cluster members cannot synchronize interface states, resulting in link instability, frequent flapping, and interrupted traffic. Traffic drops occur because the secondary's mismatched LAG is unable to pass traffic in the same manner as the primary, violating HA consistency requirements. This matches the symptom, making it the correct root cause.

To forward logs to FortiAnalyzer, you must explicitly configure it as a remote logging destination under Log & Report > Log Setting. You add the FortiAnalyzer's IP address, specify the log types to transmit, and set the upload schedule or real-time mode. This action enables the FortiGate to establish a session using the FortiTelemetry protocol (or FortiTelemetry over SSL/TLS) and stream logs to FortiAnalyzer, which then stores them centrally and provides reporting and analysis.

An IPS sensor must be explicitly applied to the same firewall policy that references the SSL/SSH inspection profile. After the SSL/SSH proxy decrypted the traffic, the flow or proxy engine passes the decrypted payload to the IPS sensor, which matches it against configured intrusion signatures and enforces the defined action. Policy-level binding is essential: without both the SSL/SSH profile and the IPS sensor on the same policy, the FortiGate cannot inspect the decrypted content for threats.

The HA override setting directly controls preemption after recovery: when override is disabled, a formerly failed primary that rejoins the cluster negotiates as a standby and does not force the active unit to step down, even if it has a higher configured priority. This exactly matches the described behavior of an active-passive cluster that stays with the current primary after the original primary recovers. Since override is disabled by default on FortiGate, the cluster remains in its current role assignment.

Data interfaces may have fluctuating link status, triggering failover.

FortiClient EMS is the cornerstone of Fortinet's ZTNA solution because it collects and reports user identity, endpoint inventory, and device compliance posture to FortiGate. FortiGate then uses this telemetry and EMS tags to make per-session, application-aware access decisions based on the endpoint's trust level. This identity and posture verification is what ZTNA needs to ensure that only authorized users on healthy devices can reach internal applications.

This sequence enables real-time flow debugging filtered to destination port 443, with function-name output to display each FortiOS inspection stage (e.g., SSL proxy, application control, IPS). The 'diagnose debug enable' command activates the trace, streaming event details to the console as the packet traverses the engine. It is the most direct way to pinpoint exactly where an HTTPS session is accepted, decrypted, blocked, or dropped.

The HA heartbeat link is the liveness mechanism between cluster members. High packet loss or jitter on that link causes heartbeat messages to be dropped, leading the standby unit to believe the primary is unhealthy and triggering a failover. This can result in repeated failover flaps as the primary is falsely deemed dead, then recovers. For this reason, FortiGate recommends a dedicated, reliable physical interface for HA heartbeat, not a link prone to congestion or loss.

diagnose sniffer packet is the correct FortiGate CLI command for capturing raw packets on an interface. It accepts an interface name (or 'any'), a BPF filter, a count, and a verbosity level, functioning much like tcpdump. This command provides direct visibility into the actual frames on the wire, making it the go-to tool for packet-level troubleshooting.

In FortiGate active-active HA, session synchronization is not automatic — it must be enabled individually on each firewall policy using the 'session sync' option in the policy's advanced settings. Without this setting, each session is tracked only by the specific cluster unit that received its first packet, and if that unit fails or return traffic is load-balanced to a peer, the session is unknown to the other unit. This directly prevents the session table from being shared, which is exactly why the administrator observes no session synchronization.

Enabling session-pickup under the 'config system ha' block instructs the FortiGate to send session table information to the secondary unit on a continuous basis, allowing the standby to have a warm copy of all active connections, including those generated via virtual IPs. When a failover occurs, the backup unit has the necessary state to keep those VIP sessions active, so users do not experience a disruption. This is the central mechanism that makes stateful failover possible in FortiGate HA and is also required for sessions that originate through the VIP to be resumed on the new active device.

In an active-passive HA cluster, the session pickup feature continuously synchronizes the session table from the primary unit to the standby unit, so that the standby can take over existing sessions seamlessly on failover. When session pickup is enabled, the secondary unit maintains a fully updated copy of all session entries, and the newly active unit can continue forwarding traffic for those connections without interruption. If this setting were disabled, all sessions would need to be re-established after a failover, causing connection drops for clients.

Session synchronization replicates the full state of active sessions—including TCP sequence numbers, NAT translations, and timers—from the unit that owns the session to every other member of the cluster. If the owning unit fails, a peer that has an identical session record can immediately resume forwarding traffic without requiring clients to re-establish their connections. This stateful takeover is critical for seamless failover in high-availability clusters.

The expire counter shows the remaining lifetime before FortiGate removes the session from its session table, decrementing each second from the configured timeout. With proto_state=01 confirming an established TCP session, expire=3599 means roughly one hour remains before idle timeout eviction, directly answering what the field indicates.

Traffic logs are written by the FortiGate session table when a flow matches an explicit or implicit firewall policy. Each entry records the policy ID, session ID, source and destination IP/port, interfaces, NAT translations, and byte/packet counts for both directions. They also indicate the action taken, such as accept, deny, or SSL-negotiation failure. This is the dedicated log type for reviewing which firewall policies allowed or blocked specific sessions and how much bandwidth they consumed.

This command displays the HA cluster status, including which unit is primary, the HA uptime, and the priority of each member. It provides a concise summary directly from the CLI, making it ideal for quickly verifying the active unit and its attributes in an active-passive setup.

Enabling 'override' in the HA configuration is the correct way to allow a higher-priority unit to preempt and become primary again after it recovers from a failure. When 'override' is enabled, the cluster continuously compares the priority of all units, and if a unit with a higher priority comes back online, it will actively take over the primary role. This ensures that in an active-passive setup, the preferred primary unit will regain mastership after a failover, instead of letting the secondary remain as primary indefinitely. The command is configured under 'config system ha' and is essential for automatic failback.

An IPS profile contains signatures and anomaly detection rules that inspect traffic for known vulnerabilities, exploits, and attack patterns. By applying this profile to the firewall policy, the FortiGate can block malicious packets in real time, which directly addresses the requirement to secure the specific traffic flow. Without the profile, even with flow-based inspection enabled, the device would not have the rulebase to identify intrusion attempts.

When you run 'diagnose debug flow', the output includes a log line that states the matching policy ID, for example "op=... policyid=..." for each packet. By reviewing the firewall policy list and looking up that specific policy ID, the administrator can directly inspect the action, schedule, source/destination addresses, and services configured on that policy to determine why it is handling the traffic unexpectedly.

Active-passive is the standard FortiGate HA mode in which one cluster unit holds the primary/active role and processes all production traffic, while the second unit remains in standby, synchronizing configuration and (if session pickup is enabled) session state via the dedicated HA heartbeat link. When the active unit fails or loses heartbeats, the standby unit is promoted to active and takes over the virtual cluster interfaces, providing transparent failover with minimal disruption.

The 'diagnose sys ha status' command displays detailed HA status information, including the current primary unit, HA mode, cluster uptime, and the status of each member. It is the correct command to quickly assess the HA cluster's health and roles. This command is commonly used for troubleshooting and verification.

Setting 'override enable' is the correct way to make a higher-priority FortiGate unit reclaim the primary role in a cluster. When enabled, a unit that becomes healthy and has a higher configured priority than the current primary will preempt the role back, ensuring the preferred unit resumes active control. This is essential for deterministic failback after maintenance or an outage, because without override the lower-priority unit would stay primary until it fails.

After uploading the firmware to both units, the administrator should log into the secondary unit via 'execute ha manage 1' and then use 'execute restore image' to install the new firmware. This upgrades the secondary first, then the primary can be upgraded later, minimizing downtime. This is the recommended HA firmware upgrade procedure.

The `diagnose sniffer packet` command is FortiGate's built-in packet capture utility, equivalent to tcpdump. It allows you to capture raw packets on one or more interfaces with flexible BPF-style filters (e.g., host, port, protocol) and verbosity levels (1 for headers, 2 for headers+payload, 3 for full packet details). This is the canonical command for performing a packet capture on FortiGate, making it the correct answer for capturing packets.

This command queries the HA daemon's internal statistics and specifically reports the number of consecutive sent and received heartbeat packets as well as the computed packet loss rate. It is the only command in this list that directly measures the reliability of the heartbeat link, which is essential for diagnosing intermittent failovers or a split-brain condition. A non-zero loss percentage here indicates a degraded heartbeat path, pointing to physical-layer issues such as bad cables, duplex mismatches, or congested interfaces.

Enabling UDP session synchronization directly instructs the FGCP cluster to replicate UDP session table entries from the primary unit to the standby. Because UDP is connectionless, the standby cannot infer active flows from handshake packets, so without this explicit setting, return traffic for existing UDP conversations will be dropped after failover. This setting is protocol-specific and works alongside session pickup to ensure NAT bindings and idle timers are preserved on the new primary.

The correct workflow in FortiOS for inspecting the session table is to first set a filter with 'diagnose sys session filter dport 443', which configures the current CLI session to show only sessions with a destination port of 443. Then 'diagnose sys session list' prints the matching entries from the kernel session table. This two-step approach lets you combine multiple filter criteria without passing them as command arguments.

Emergency (severity 0) is the highest syslog severity level and specifically denotes that the system is unusable. On FortiGate, this log is generated when a fatal condition halts operations, such as a kernel panic or a catastrophic disk failure that prevents booting. Unlike lower severities, Emergency means the device cannot perform its security functions or be administered until it is restarted or repaired.

FortiAnalyzer is Fortinet's dedicated log management and analysis appliance, purpose-built to aggregate logs from FortiGate and other Fortinet devices to a central location. It provides high-capacity storage, real-time search, reporting, and event correlation, making it the standard for enterprise centralized logging. Configuring FortiGate to send logs to FortiAnalyzer via the FortiGate's log settings or Security Fabric fully meets the organization's central log collection need.

Offloading new logs to FortiAnalyzer frees local disk space while retaining compliance evidence, and archiving existing logs before clearing preserves them. This satisfies the stem's dual constraint: continue logging and keep the current logs, which simply deleting or disabling logging would violate.

TCP, or Transmission Control Protocol, is indeed assigned IP protocol number 6, which is what the session filter output indicates. This is standard across all IP networks, as defined by the IANA protocol numbers. A FortiGate session for applications such as HTTP, SSH, or SMTP would show 'Proto=6' to represent TCP. Therefore, the correct interpretation of the protocol numeral in the diagnostic output is that the session is using TCP as its transport layer protocol.

The failover threshold (often called the missed-heartbeat threshold) specifies how many consecutive heartbeat packets from the primary must be lost before the secondary unit declares a failover. Increasing this threshold from the default of 3 to a larger value allows the cluster to tolerate small bursts of packet loss or a momentary HA link issue without triggering a failover. This directly reduces spurious failovers while still detecting a true primary outage if the primary remains silent for a longer period, making it the correct corrective action.

A valid FortiCloud subscription is mandatory because FortiCloud logging is a licensed cloud service. The FortiGate must authenticate to FortiCloud's servers using the registered account's credentials and entitlement; without an active subscription, log upload attempts will be rejected even if local disk storage is available. This subscription is a hard prerequisite that cannot be bypassed by configuration alone.

Event logs are the correct FortiGate log type for authentication records, as they capture administrative login/logout, user authentication attempts, and enforcement of authentication policies. They also log configuration changes and system policy events, making them the central repository for user-access accountability. For example, both successful and failed logins via the web GUI or SSH are written to the event log with timestamps and source IPs.

After DNAT, the destination IP changes to the internal server. The firewall policy must allow traffic to that internal IP. If the policy's destination is set to the VIP's public IP, it may not match post-DNAT. The correct approach is to set the destination to the mapped IP address.

Enabling session pickup is essential for stateful failover in a FortiGate HA cluster. It synchronizes the session table, including NAT translations, TCP/UDP state, and even application-layer protocol states, between the primary and standby units. This ensures that when a failover occurs, existing connections are not dropped and can continue seamlessly on the new primary. Without session pickup, even if the interface goes down and failover is triggered, all active sessions would be lost, causing disruption to users.

Session synchronization's core purpose is to ensure stateful high availability: if one firewall unit fails or is taken out of service, the cluster's other unit(s) already possess the full session information—including NAT mappings, TCP sequence state, and application-level data—required to continue forwarding traffic without resetting connections. This is achieved by continuously transmitting session updates over the HA heartbeat link from the unit that owns each session to its standby or peer units. By doing so, the cluster can fail over in milliseconds, and existing sessions survive the failure. This is fundamental to delivering uninterrupted connectivity in an enterprise network.

Emergency (severity 0) is the highest log severity level and is reserved for situations where the FortiGate system is completely unusable, such as a kernel panic, total configuration failure, or unrecoverable hardware fault. This level indicates that the firewall cannot perform any of its security functions, and immediate intervention is required, which is exactly what the question asks to identify.

'diagnose sys session list' is the correct command to view the current session table. It reads the kernel session table and outputs every active connection, including source/destination IP addresses, ports, protocol, session state, and timers. This is the standard tool for troubleshooting NAT, policy, and asymmetric routing because it shows exactly what the firewall is tracking in real time.

Event logs are the correct log type for user authentication events. They record auditable system events, including successful and failed login attempts for administrators, VPN users, and other service accounts, as well as authentication failures and lockouts. Event logs are specifically designed to capture user authentication and accounting information for security auditing.

This command runs a trace of a specific user-selected packet or flow through the FortiGate's processing pipeline, displaying each stage including policy lookup, routing decisions, and the final action (accept or drop). It captures the exact policy ID matched and the reason for any drop, such as implicit deny or traffic-shaping constraints. As a debug utility, it is the proper tool for verifying the policy decision for a given flow, making it the correct answer.

The 'diagnose debug flow' command is the definitive real-time tracing tool for FortiGate traffic. It allows you to apply filters (e.g., by source IP, destination IP, port, or VLAN) and then traces each packet through the entire data path, showing the exact policy ID matched, the action taken (accept or drop), and any profile-based processing or session errors. This output directly answers the question of 'which policy did this traffic match?' making it the correct troubleshooting method.

The correct procedure is to upgrade the standby unit first, verify it has booted and joined the cluster with a healthy synchronization, then manually fail over so that the upgraded unit becomes primary and handles traffic. After that, upgrade the former primary (now standby) to the same version, ensuring both units finally run identical firmware. This rolling upgrade preserves a live unit for every step, avoiding an outage and keeping the HA pair in a supported configuration throughout.

The session's proto_state value of 01 corresponds to SYN_SENT, indicating the client's SYN has been sent but no SYN-ACK has yet been received from the server. This creates a half-open session that is stuck waiting for the server to respond, often due to packet loss, a misconfigured server, or an intermediate device silently dropping the SYN-ACK. Until that reply arrives, the session cannot transition to the fully established state.

The ZTNA gateway is the correct answer because it is the network entity that accepts inbound client connections, terminates the TLS session, authenticates the user, validates ZTNA tags, and proxies the session to the configured ZTNA application. In FortiOS, you configure a ZTNA gateway with a virtual host, a port, and an SSL certificate. This is where the client's connection logically ends and the internal connection to the backend application begins.

The 'management IP' field under the HA configuration is the correct method because it defines a floating IP (with optional netmask and gateway) that is owned by the primary unit and automatically moves to the failover unit during a failure. This IP is not a regular interface IP; it is added as an alias on the primary unit's management interface, enabling uninterrupted HTTPS management of the cluster via the same address before and after failover. Ensure the management IP is on the same subnet as your management network and that you allow HTTPS on that interface.

This correct sequence first installs a flow trace filter for the source IP, then selects the `function-name` output mode to display the names of kernel functions that process the matching packets, and finally enables debug output. The order is critical because the filter must be active before debugging starts to avoid capturing unrelated traffic, and the `show` option must be set before `enable` takes effect. Once enabled, the FortiGate outputs a step-by-step traversal of the packet through the firewall, including policy lookups, session setup, and any drops, which is exactly what real-time debugging requires.

When override is enabled in FortiGate HA, a device with higher priority can preempt the current primary when it comes back online after a failover. Without override, the cluster maintains the current primary even if a higher-priority unit is available, so the original primary remains active after recovery. This is exactly the observed behavior: the higher-priority unit is primary initially, fails over, and on recovery does not reclaim primary because override is off. The priority is used for initial election and for override-based decisions, but failback requires override enabled.

The 'best quality' strategy only fails over when the configured SLA performance criteria are breached. If the performance SLA monitors latency alone, high jitter never triggers a member failure, so traffic stays on the fiber link despite exceeding the jitter threshold.