CCNA Nse4 Ha Diagnostics Questions

The 'diagnose debug flow filter src' command sets a source IP address filter that restricts the real-time flow debugging output to traffic originating from that specific host. This is the correct first step when you want to trace a particular user's or device's session flow through the FortiGate, because it prevents the console from being flooded with all traffic and makes the output meaningful. After setting this source filter, you must also run 'diagnose debug flow show console enable' and then 'diagnose debug enable' to see the live flow trace messages on the CLI.

The 'diagnose sys session stat' command is the correct choice because it directly reports session table statistics, including the current number of sessions, the configured maximum, and the utilization percentage. These metrics allow the administrator to quickly determine whether the FortiGate is approaching its session limit, which can cause new connection failures and slow performance for web applications. This command is purpose-built for assessing session-table pressure and is the most efficient way to diagnose session exhaustion.

In active-passive HA, the standby unit does not have the active unit's session table unless session pickup (session synchronization) is enabled and functioning. When a failover occurs, the newly active unit has no knowledge of the established TCP connections, so it cannot forward packets for those flows and they must be re-established. If session sync is enabled but not working, the same result occurs, so the correct fix is to verify that the session pickup feature is properly configured and that heartbeat interface is carrying the synchronization updates.

FortiGuard Web Filtering is the subscription service that provides comprehensive URL categorization and filtering, using a cloud-based database to classify websites into categories such as malware, Phishing, or gambling. This service enables FortiGate to enforce web access policies by comparing requested URLs against category and reputation data in real time. Without this subscription, URL filtering is unavailable, so it is the correct choice for this requirement.

When local logs are missing, the first step is to verify the storage subsystem with 'diagnose sys disk' to inspect disk health, mount status, and available space. A full or failing disk, or an exhausted inode table, can cause log writes to fail silently, resulting in no entries in the local log view. This command reveals whether the disk is online, has sufficient free blocks, and has no file-system errors. Only after confirming the disk is healthy should you examine logging filters or remote destinations.

This command displays a concise summary of the HA status, including the primary unit's hostname, priority, and HA uptime. It is the standard command to quickly verify which unit is primary and its attributes. It works on either unit and provides the necessary information directly.

diagnose sniffer packet is the Fortinet CLI command that invokes the built-in packet capture engine to display live packets as they traverse the specified interface(s) or VLAN(s). It accepts real-time filters such as 'port 443' or host IPs, and a verbosity level (1-6) controlling header vs. full payload display. Because it immediately streams captured frames to the terminal, it is a legitimate real-time traffic-viewing tool.

`diagnose sys session stat` is the correct first command because it presents a concise summary of session table statistics, including totals for sessions in various states such as TCP SYN-SENT, SYN-RECV, ESTABLISHED, FIN-WAIT, and others. By observing an unusually high count in the SYN-SENT bucket, an administrator can quickly confirm whether incomplete (half-open) connections are accumulating and contributing to the performance problem. This aggregate view is fast, non-intrusive, and gives immediate insight into the session table distribution without listing individual sessions.

Set the FortiAnalyzer as the log destination in Log Settings. Under System > Log Settings (or via CLI 'config log fortianalyzer setting'), the administrator must specify the FortiAnalyzer IP address and enable log transmission. This action directs the FortiGate to send logs using the native FortiAnalyzer protocol, which provides reliable, acknowledged log delivery. Without this configuration, logs will never leave the FortiGate, regardless of any firewall policies or forwarding rules.

The debug flow output's 'Deny by policy' verdict means the FortiGate's firewall policy engine evaluated the packet against the configured policy set and explicitly rejected it, typically due to the absence of a matching permit policy, a matching explicit deny policy, or a policy that disallows the tuple (source, destination, service, user, etc.). Because the packet is denied before session creation, the administrator should inspect the policy list with `diagnose firewall policy list` or via the GUI, and either adjust the existing policy's matching criteria/action or create a new permit policy that allows the legitimate traffic. Correctly aligning the policy to the intended traffic flow is the direct and standard fix, avoiding unnecessary service disruption.

FortiGuard Antivirus Service is responsible for delivering up-to-date antivirus engines and virus signature files to the FortiGate, enabling scanning of files, email attachments, and web downloads for known malware. When the administrator sees an alert that antivirus signatures are outdated or failed to update, this is the subscription service to verify and troubleshoot. Without this service, the FortiGate cannot reliably block malicious content based on virus definitions. Therefore, it is the correct choice.

This is the correct method because it establishes the native, authenticated FortiAnalyzer connection. Under System > FortiAnalyzer, you specify the FortiAnalyzer IP address, set an access token or serial number, and enable logging; this configures the FortiGate to use FortiAnalyzer's proprietary logging protocol (FAS) with features like log buffering, encryption, and compression. The CLI equivalent, 'config log fortianalyzer setting', offers the same options and is often used in automated deployments. Once configured, the FortiGate begins forwarding all configured log types to FortiAnalyzer for centralized logging, analytics, and reporting.

Enabling HA override allows a unit with a higher priority to take over as primary when it becomes available, even if another unit is currently primary. This ensures the preferred unit always becomes primary after a reboot or failure, as long as it is operational. Override must be enabled on the unit that should become primary.

A duplex mismatch on the heartbeat interface is the classic cause of intermittent heartbeat loss: one side runs at full duplex and the other at half duplex, leading to late collisions, CRC errors, and frame drops that tend to occur in bursts. These dropped frames are exactly what the HA process sees as a missing heartbeat. If the heartbeat timeout is repeatedly exceeded, the cluster concludes the peer is down and triggers a failover; once traffic resumes, another lost burst starts the cycle, producing the observed frequent failovers.

Session synchronization is not enabled. In an active-passive HA cluster, the primary FortiGate maintains the complete session table for all inspected traffic. If session synchronization (or session sync) is not configured via the HA settings, the backup unit does not receive real-time updates about existing sessions. Upon failover, the newly active unit has no entries for these flows, so when endpoints continue sending packets, the FortiGate cannot match them to a session and drops them—causing established TCP connections to break and requiring applications to reconnect. This is the direct cause of the session loss observed.

Traffic logs are the correct answer because they are generated when a session is evaluated against a firewall policy and contain the matching policy ID, action (accept or deny), source/destination IP addresses, ports, protocol, and bytes transferred. These logs let administrators verify which policy handled a given connection, monitor traffic volumes per policy, and troubleshoot connectivity issues. They appear under Log & Report > Traffic Log and serve as the foundation for FortiView session monitoring and policy-based reporting.

A ZTNA server defines the internal application's host and port, while a ZTNA rule (configured in the firewall policy) specifies who can access it and what access proxy settings apply. Together they establish the FortiGate as an access proxy that authenticates users and enforces least-privilege access. Without these two objects, the FortiGate has no way to publish or protect the application, making them the core requirement for zero-trust network access.

Emergency is the highest severity level (0) in FortiGate's logging hierarchy and specifically denotes that the system is unusable, as seen with a kernel panic, critical hardware failure, or complete resource exhaustion. When a FortiGate logs at Emergency severity, the device has either crashed or lost its ability to function, requiring manual intervention or a reboot. This exact definition matches the question's criterion, confirming Emergency as the correct answer.

In FortiGate active-active HA, session synchronization is triggered periodically (default every 200 ms) as well as on immediate state changes such as session setup or teardown. Because of this periodic timer, a newly created session is typically copied to the secondary within a few hundred milliseconds to a couple of seconds, giving the secondary nearly up-to-date state without the performance overhead of instantaneous synchronous replication on every packet.

A correct fix is to set the SD-WAN rule to use the broadband link as a secondary strategy when the primary MPLS link fails its performance SLA. In Fortinet, this is done by listing multiple link members in the rule and specifying a strategy such as 'best quality' or 'SLA' where the next available member is used as a backup. The rule then automatically moves voice traffic to broadband whenever the MPLS link violates the configured latency threshold.

The correct approach is to enable two independent log destinations in the FortiGate's log settings: first, set the local disk as a log destination (config log disk set status enable), and second, add and enable the FortiAnalyzer as a remote log server (config log fortianalyzer set status enable set server <fortianalyzer_IP>). Each destination is configured in its own block with its own severity/filter settings, and FortiGate will deliver logs to both simultaneously once both are enabled. This matches the requirement to send logs to both a local disk and a FortiAnalyzer without any dependency between the two.

For HA heartbeat to work, the heartbeat interfaces on both FortiGates must be in the same subnet, typically via a direct crossover connection or through a switch on the same VLAN. This is because heartbeat packets are sent as Ethernet frames (often multicast) and require Layer 2 adjacency; without a shared broadcast domain, the units cannot detect each other or exchange session-synchronization data. If the heartbeat interfaces are on different subnets, the HA cluster will never form.

The `diagnose sniffer packet` command is the definitive FortiOS CLI for real-time packet capture. It allows you to specify an interface (e.g., `any`, `port1`), a BPF-style filter (e.g., `host 10.0.0.1`), and a verbose level (0-4) to inspect raw packet headers and payloads as they traverse the FortiGate. This is the standard tool for live traffic analysis and packet-level troubleshooting.

The debug flow output showing 'no matching policy' means the packet successfully completed route lookup and is now being matched against firewall policies. This error occurs when no enabled policy satisfies the traffic's characteristics, such as the ingress interface, egress interface, source/destination addresses, or destination port. A disabled policy is ignored entirely, and if the source or destination interfaces in a policy do not match the actual interfaces the traffic traverses, that policy will be skipped, leaving the traffic without a match.

SD-WAN rules are evaluated in order of priority, meaning the rule with the lowest priority number (highest precedence) is inspected first and the first matching rule is applied exclusively. FortiGate processes rules top-down, and once a match is found, no subsequent SD-WAN rule is considered for that session, making priority sequencing critical for deterministic traffic steering.