I85PREP
⌘ K
CCTE R81.20 study materials
CCTE R81.20 study resources

CCTE R81.20: Troubleshooting Methodology and Tooling

CCTE R81.20 · Work through your exam, one topic at a time.

All guide sections

Troubleshooting Methodology and Tooling

Domain 1 tests whether you can move from symptom to evidence in a controlled order across R81.20 management, gateway, and data plane. The exam favors structured isolation and correct tool selection over random command memorization.

Establish scope and layer

  • Write the symptom as a testable statement: source, destination, service, direction, frequency, and affected gateways.
  • Decide whether the fault is management-plane (GUI/API/policy install), control-plane (routing, cluster, SecureXL), or data-plane (packet drop, NAT, inspection).
  • Check what changed: policy install, upgrade, routing change, certificate, license, cluster failover.
  • Capture a baseline with cpstat, CPView, interface counters, and recent logs before changing anything.

Map tools to evidence

  • cpinfo produces a support snapshot; use it after you have a hypothesis, not as the first diagnostic.
  • CPView shows real-time CPU, memory, interfaces, and connections; cpstat fw and cpstat os show subsystem counters.
  • fw monitor shows packets at firewall inspection points; tcpdump and cppcap show wire or accelerated-path packets.
  • fw ctl zdebug and fw ctl debug expose kernel decisions; SmartLog and SmartEvent show policy matches and drops.

Worked example

Users report intermittent HTTPS failures through one gateway. First check SmartLog filtered to the client/server and port 443: if drops appear, note the rule and reason. Next run fw monitor -e 'accept port 443 and host 203.0.113.10;' on the gateway. If packets appear at i and I but not o, the gateway received them and policy/NAT/inspection is the likely cause; if they appear at i only, inbound processing or anti-spoofing is suspect; if absent at i, check upstream routing and interface counters. Then run fwaccel stat because accelerated traffic can change where captures appear. This sequence avoids enabling kernel debug before you know which side of the firewall loses the packet.

Traps

  • Running fw ctl debug without a module and filter, then forgetting to reset it.
  • Treating fw monitor points as interchangeable; i/I are inbound before/after inspection, o/O outbound.
  • Ignoring SecureXL acceleration and concluding the firewall never saw the packet.
  • Using management-server captures to diagnose gateway forwarding.
  • Comparing logs from systems with different time zones without normalizing.