The company's Panorama server (IP 10.10.10.5) is not able to manage a firewall that was recently deployed. The firewall's dedicated management port is being used to connect to the management network.

Question

Options

• Atest panoramas-connect 10.10.10.5
• Bshow panoramas-status
• Cshow arp all I match 10.10.10.5
• Dtopdump filter "host 10.10.10.5
• Edebug dataplane packet-diag set capture on

• A
  4% (1)
• B
  78% (21)
• C
  15% (4)
• E
  4% (1)

Explanation

show panorama-status (B) directly displays the firewall's connection state to Panorama, showing whether it's connected, disconnected, or pending - the most targeted first step when Panorama can't manage a device. tcpdump filter "host 10.10.10.5" (D) captures packets on the management interface, letting you verify whether traffic is actually reaching Panorama or being dropped somewhere in the path.

Why the distractors are wrong:

• A (test panoramas-connect) uses invalid syntax - no such command exists in PAN-OS in that form.
• C (show arp all | match 10.10.10.5) checks Layer 2 ARP mappings; useful for basic reachability but not specific to Panorama connectivity and won't reveal application-layer issues.
• E (debug dataplane packet-diag) captures traffic on the dataplane interfaces - Panorama management traffic flows over the management plane, so this captures the wrong traffic entirely.

Memory tip: Think "Status + Sniff" - first check the Status of the Panorama connection (B), then Sniff the wire with tcpdump (D). Both tools operate on the management plane where Panorama communication lives; anything touching the dataplane is the wrong layer for this problem.

No community discussion yet for this question.