I85PREP
⌘ K
Cisco 300-710 SNCF study materials
Cisco 300-710 SNCF study resources

Cisco 300-710 SNCF: Troubleshooting and Verification

Cisco 300-710 SNCF · Work through your exam, one topic at a time.

All guide sections

Troubleshooting and Verification

Domain 5 is the largest area: proving what the device did with a packet and fixing configuration or deployment faults. Expect questions on which tool answers which question and on interpreting CLI output.

Layer-by-layer verification

  • Did the packet arrive? FMC-driven capture (Device > Capture) with a match ACL, or the trace feature that captures at ingress and egress for a specified 5-tuple. Captures are buffered on the device and lost on reload.
  • Which rule matched? Analysis > Connections shows the ACP rule, action, block reason, and whether Snort inspected the flow. An empty event list often just means logging is disabled on that rule or default action.
  • Was it an IPS drop? Look for 'blocked by snort rule' with the GID:SID in the connection event, then check that SID's state in the intrusion policy.

Device and tunnel checks (FTD CLI)

  • show managers confirms the registered manager and connection state.
  • show sftunnel status and show sftunnel interface verify the tunnel to FMC; TCP 8305 must be permitted.
  • show ntp status; clock skew breaks registration and corrupts event timelines.
  • show interface, show route, show nat, show access-control-config, and show snort statistics cover data-plane and inspection health.
  • system support diagnostic-cli drops to the LINA/ASA-style shell for packet-tracer and capture on routed deployments; use show tech or an FMC-generated troubleshoot file for support.

Deployment and health

  • A failed deploy is a Task Status / Message Center problem, not a health alert. Typical causes: interface missing on the target, object or zone absent, a Snort 2 policy applied to a Snort 3 device, or a device out of license.
  • Health Monitor reports CPU, disk, interfaces, and Snort status; check it before blaming policy.

Worked example

Users lose access to an internal app after a push. Check connections for the flow: a 'blocked by access control rule' reason means read the rule name and fix ordering; an allow with no response means run a trace and check FTD routing and NAT for the return path; no event at all means capture on the inside interface to see whether the packet arrives.

Traps

  • Concluding 'allowed' from an empty event list.
  • Running captures without adequate buffer size, then seeing nothing.
  • Looking in Health Monitor for a policy deploy failure.
  • Testing a flow whose return traffic never reaches the FTD.