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

CCTE R81.20: Traffic Inspection, Logging, and Debugging

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

All guide sections

Traffic Inspection, Logging, and Debugging

Domain 4 tests packet-level inspection, log interpretation, and safe kernel debugging. The exam expects you to choose fw monitor, cppcap, tcpdump, SmartLog, and fw ctl debug for different evidence and to avoid leaving debug enabled.

Packet capture points

  • fw monitor shows four points: i inbound before inspection, I inbound after inspection, o outbound before inspection, O outbound after inspection. Use the pattern to localize loss.
  • Filter at capture time: fw monitor -e 'accept host 198.51.100.20 and port 443;'. Unfiltered captures on busy gateways are misleading and expensive.
  • cppcap captures on the accelerated path; tcpdump shows the wire. Neither replaces firewall inspection points when you need policy verdicts.

Logs and verdicts

  • SmartLog records rule match, action, NAT, and drop reason. A missing log is evidence: check track settings, implied-rule logging, and whether acceleration bypassed logging.
  • Correlate timestamps and time zones across management and gateway before comparing captures with logs.
  • Use log fields such as blade, rule number, and NAT source/destination to reconstruct the path.

Debugging

  • Prefer fw ctl zdebug -m fw + drop for a quick live drop trace; it is temporary and terminates with Ctrl-C.
  • For controlled debug, use fw ctl debug -m <module> + <flags>, write with fw ctl kdebug -f, then reset with fw ctl debug 0. Always scope to a filter if supported and document the reset.
  • Debug output is kernel-level and can affect performance; never leave it running on a production gateway.

Worked example

A site-to-site VPN tunnel drops large transfers. Run fw monitor -e 'accept src=192.0.2.10 and dst=198.51.100.30;' on the gateway. Packets appear at i and I, but only small packets appear at o. That suggests fragmentation, MTU, or VPN encryption path issues, not a policy drop. Check fw ctl zdebug -m fw + drop for a drop reason; if no drop appears, inspect interface MTU and TCP MSS adjustment. SmartLog shows accepts, so policy is not the cause. The reasoning: capture points show the packet entered and passed inbound inspection; failure after inspection points to outbound encapsulation or MTU.

Traps

  • Running fw monitor on the management server.
  • Leaving fw ctl debug enabled after collecting data.
  • Capturing without a filter and misreading unrelated flows.
  • Assuming no log means no drop; check implicit rules and acceleration.
  • Mixing UTC and local timestamps when correlating.