Troubleshooting Scenario Questions

Topology View

Why it fails: The Topology View displays the network topology, including sites, links, and overlays, but it does not show the detailed policy rules or their evaluation. It can help visualize connectivity but lacks the granular policy information needed to troubleshoot why a specific VLAN's traffic is not being forwarded correctly. Therefore, it is not the best tool for verifying effective policy.

Event Log

Why it fails: The Event Log records system and policy events, such as alarms and configuration changes, but it does not provide a view of the effective policy or path selection logic. While it might show policy-related events, it does not offer the comprehensive policy evaluation details needed to diagnose a VLAN forwarding issue. Thus, it is not the appropriate tool for this task.

Flow Analytics

Why it fails: Flow Analytics provides detailed flow-level data, such as source/destination IP, ports, and application identification, but it does not show the effective policy configuration or how path selection decisions are made. While it can confirm whether traffic is flowing, it does not explain why a particular path was chosen or if a policy rule is misconfigured, making it less suitable for verifying policy application.

The device's management interface is configured with a static IP address.

Why it fails: A static IP address on the management interface is not required for control connection establishment. The device can use DHCP or other methods to obtain an IP. The control tunnel is established over the WAN interface, not the management interface, so this check is irrelevant to the described issue.

The device's local firewall is allowing outbound UDP port 4500.

Why it fails: While UDP port 4500 is used for NAT traversal in IPsec, the control connection to the Prisma SD-WAN Controller typically uses TCP port 443. Blocking UDP 4500 might affect data plane tunnels, but it would not prevent the control connection from forming due to certificate or licensing issues. This is a connectivity check, not an identity check.

The device's software version matches the controller's version exactly.

Why it fails: While version compatibility is important, the controller supports a range of software versions and does not require an exact match. Mismatched versions might cause feature discrepancies, but they do not prevent the control connection from forming due to identity or authorization failures. This is not a primary check for certificate or licensing issues.

Increase the bandwidth of the ISP link used by the Service Connection to Prisma Access.

Why it fails: Increasing ISP bandwidth does not fix the routing problem. Internal traffic is still being sent to Prisma Access, adding latency regardless of bandwidth. The issue is policy steering, not link capacity, so this change would not resolve the slowness.

Disable Dynamic Path Selection on the Service Connection to force traffic over a single path.

Why it fails: Disabling Dynamic Path Selection does not change where internal traffic is sent. It may reduce resiliency and does not address the backhaul of internal traffic to Prisma Access. The traffic would still be inspected unnecessarily, so performance would not improve.

Configure a static route on the ION device that points internal prefixes to the Prisma Access tunnel.

Why it fails: This would reinforce the incorrect behavior by explicitly sending internal prefixes to Prisma Access. The goal is to keep internal traffic on the SD-WAN fabric, not to route it to the cloud. This change would worsen the latency issue.

Review the application performance dashboard to see if any applications are experiencing latency.

Why it fails: Application performance dashboards show traffic metrics for applications that are already flowing. If no traffic is being forwarded, these dashboards would show no data, providing no insight into the interface issue. This step is irrelevant until basic connectivity is restored.

Check the BGP neighbor state to ensure the peering session with the service provider is established.

Why it fails: BGP neighbor state is relevant only if BGP is configured and the underlying IP connectivity is working. Since the interface is not passing traffic, BGP would not be able to establish anyway. Troubleshooting BGP before verifying basic IP configuration is premature and would not address the root cause.

Restart the ION device to force a renegotiation of the interface and DHCP lease.

Why it fails: Restarting the device is a disruptive action that should be a last resort. It does not help diagnose the problem and may temporarily mask the issue. The engineer should first gather information about why the interface is not passing traffic, such as checking DHCP status, before considering a restart.

The ION device is missing the latest firmware

Why it fails: Firmware version does not govern whether traffic matches a Unified SASE policy; an outdated ION image would affect forwarding generally, not selectively block Cloud SWG reachability. Firmware upgrades address device defects, whereas policy misconfiguration or missing traffic steering rules cause this symptom.

The Cloud Identity Engine is not reachable

Why it fails: The Cloud Identity Engine supplies user and group identity for policy evaluation; it is not the forwarding path, so its unreachability would not stop traffic reaching Cloud SWG. It is tempting because identity outages do break policy, and would be correct when traffic is dropped due to failed user-to-group resolution rather than path selection.

The WAN port is set to DHCP

Why it fails: DHCP on the WAN port only affects how the ION obtains its own public address; it cannot prevent Unified SASE policy from steering traffic into the Cloud SWG tunnel. DHCP is the normal choice where the ISP provides addressing dynamically, so it is valid in most branch deployments and unrelated to policy-based forwarding failures.

Application definitions

Why it fails: Application definitions are used to identify and classify traffic based on signatures, but they do not directly control how packets are marked or queued. While voice traffic must be correctly identified, the prioritization itself is handled by QoS policies. Without a QoS policy, even correctly identified voice traffic will not receive preferential treatment.

Security policy

Why it fails: Security policies control access and inspection of traffic, such as allowing or blocking applications. They do not influence how packets are marked or queued for QoS. While a security policy might inadvertently block voice traffic, the symptom of poor quality suggests the traffic is flowing but not prioritized, pointing to QoS rather than security.

Path selection policy

Why it fails: Path selection policies determine which WAN link traffic uses based on performance metrics, but they do not control packet marking or queuing. While selecting a low-latency path is important for voice, the actual prioritization on the interface is governed by QoS. Without proper QoS, voice quality can still suffer even on the best path.

Traffic log

Why it fails: The Traffic log might show general traffic statistics but does not specifically indicate firewall rule matches or drops. It is more focused on flow-level data rather than security policy enforcement. For firewall drops, the Firewall log is the appropriate source.

Event log

Why it fails: The Event log captures system and network events, such as interface up/down and routing changes, but it does not log individual firewall rule matches. It is not the right place to find why specific traffic is being blocked by a firewall rule.

System log

Why it fails: The System log contains general system events, such as reboots, software updates, and hardware errors. It does not log detailed firewall rule matches or drops. While it might show if the firewall service restarted, it won't provide the specific traffic drop information needed.

Increase the BFD hello interval on the tunnel interface to reduce sensitivity to transient latency.

Why it fails: Increasing the BFD hello interval may reduce flapping but does not isolate the root cause; it merely masks the symptom. The scenario asks to isolate the cause first, so adjusting timers before gathering diagnostic data is premature and could hide a genuine path issue such as packet loss or jitter that needs to be addressed.

Apply a QoS policy to prioritize BFD packets on the WAN interface to prevent drops.

Why it fails: Prioritizing BFD packets may help if congestion is the cause, but the scenario states the underlay is stable and counters show no errors, so congestion is not indicated. Applying a QoS policy without confirming the cause can introduce unnecessary complexity and does not help isolate why the BFD sessions are flapping.

Disable BFD on the tunnel and rely on IPsec DPD to detect failures instead.

Why it fails: Disabling BFD removes a key failure-detection mechanism and may cause slower failover, not resolution of the flapping. It also does not isolate the cause; it changes the monitoring method. The scenario requires finding why BFD sessions flap, so removing BFD would obscure the symptom rather than diagnose it.

Restart the ION device to force re-establishment of tunnels.

Why it fails: Restarting the device is a disruptive action and should not be the first troubleshooting step. It may temporarily resolve the issue if it is due to a transient state, but it does not help diagnose the root cause. More targeted checks, such as verifying NAT and IPsec settings, should be performed first.

Check the device's local routing table for a default route.

Why it fails: While a default route is important for general connectivity, the control connection is already up, indicating basic IP connectivity exists. The issue is specifically with data plane tunnels, which are established based on SD-WAN policies and tunnel configurations, not just routing. Checking the routing table is less relevant here.

Review the controller's logs for errors related to the device.

Why it fails: The controller logs might show control plane issues, but the control connection is already up. Data plane tunnel establishment is handled by the ION devices themselves, not the controller. While logs can be useful, they are less likely to reveal why IPsec tunnels are failing to form between devices.

Check the ION device's system logs for policy deny messages.

Why it fails: While system logs can show policy deny events, Prisma SD-WAN application policies do not typically deny traffic; they direct it based on application characteristics. Deny actions are usually part of security policies, not application policies. Therefore, checking for policy deny messages in system logs is unlikely to reveal why the application policy is not being applied as expected. The administrator should focus on policy configuration and traffic flow analysis instead.

Verify that the ION device has the latest software version installed.

Why it fails: While software bugs can cause unexpected behavior, intermittent packet loss on a specific application is more likely due to policy misconfiguration than a software version issue. Upgrading software is a general troubleshooting step but does not directly verify policy application. The administrator should first confirm policy configuration and flow behavior before considering software updates, which could introduce other variables.

Run a traceroute from the ION device to the application server to identify the path taken.

Why it fails: Traceroute shows the network path but does not indicate which application policy was applied. It can help identify routing issues, but packet loss due to policy misconfiguration would not be revealed by traceroute alone. The administrator needs to see the policy decision, which is available through Flow Analytics and policy stack review. Traceroute is a useful complementary tool but does not directly verify policy application.

The VPN connection to the data center is using a different encryption domain than the branch.

Why it fails: An encryption domain mismatch would typically prevent the VPN tunnel from establishing or cause traffic to be dropped, not redirected to Prisma Access. Since the application is reachable from other sites, the VPN configuration is likely correct. The issue is specific to branch routing, pointing to a route preference problem rather than encryption domain mismatch.

The Service Connection is down, causing all traffic to be dropped.

Why it fails: If the Service Connection were down, traffic to the application would likely be dropped or rerouted, but the issue is that traffic is being routed to Prisma Access, indicating the Service Connection is up. The problem is not a down tunnel but rather incorrect routing of internal traffic, so this cause is inconsistent with the observed behavior.

The application's IP is included in the local breakout policy, sending it directly to the internet.

Why it fails: If the application's IP were in a local breakout policy, traffic would be sent directly to the internet, not to Prisma Access. The scenario states traffic is routed to Prisma Access, so this cause does not match. Local breakout would likely result in the traffic never reaching the data center, but the described path is through Prisma Access, not direct internet.

System health logs

Why it fails: System health logs report device resource state, not the tunnel negotiation between an ION device and Prisma Access. Service Connection status depends on IKE and IPsec events, so the correct log type records those tunnel exchanges; system health logs would be right for CPU, memory or process faults.

User activity logs

Why it fails: User activity logs record endpoint and identity events, not tunnel state. Service Connection Down requires tunnel and IPsec logs showing IKE or peering failures. It tempts because user logs help diagnose access issues, but they cannot reveal why the ION-to-Prisma Access tunnel is not establishing.

Application performance logs

Why it fails: Application performance logs track SaaS and app metrics, not tunnel establishment. A Service Connection Down status needs tunnel and IPsec logs covering IKE negotiation and peering. It tempts because performance data helps diagnose degraded traffic, but it cannot explain why the tunnel itself is down.

Modify the default Network Policy Rule to use the Service Connection as the primary path for all traffic.

Why it fails: Modifying the default rule to send all traffic over the Service Connection would force all traffic, not just Microsoft 365, through Prisma Access. This could cause performance issues for other applications and does not selectively address the Microsoft 365 slowness. The requirement is to steer only Microsoft 365 traffic, so this approach is too broad.

Enable 'Direct Internet Breakout' on the ION device for Microsoft 365 traffic.

Why it fails: Direct Internet Breakout would send Microsoft 365 traffic directly to the internet, bypassing Prisma Access inspection entirely. The requirement is to have the traffic inspected by Prisma Access, so this action would defeat the purpose. It might improve performance but at the cost of security inspection, which is not acceptable here.

Configure a static route on the ION device for Microsoft 365 IP ranges pointing to the Service Connection.

Why it fails: Prisma SD-WAN uses policy-based routing, not static routes, to direct traffic to Service Connections. Static routes are not supported for this purpose and would not integrate with the SD-WAN fabric. Moreover, Microsoft 365 IP ranges change frequently, making static routes impractical and error-prone.

Review the OMP routes to ensure the voice prefix is advertised with the correct TLOC.

Why it fails: OMP routes advertise reachability but do not enforce application-aware routing decisions. The policy uses SLA metrics to choose among available TLOCs. While OMP is important for route propagation, it does not verify that the policy is selecting the correct path based on SLA. The issue is likely in the policy application, not route advertisement.

Check the syslog on the branch router for messages about policy failures.

Why it fails: Syslog may contain errors, but application-aware routing does not typically log policy decisions or failures at a granular level. The absence of syslog messages does not confirm the policy is working. The most reliable verification is through vManage statistics and BFD/SLA status, not syslog. Syslog is more useful for control plane or interface errors.

Run a packet capture on the voice VLAN to analyze the RTP stream.

Why it fails: Packet capture can show the actual traffic but does not directly indicate why the policy chose a particular path. It is useful for deeper analysis but not the first step to verify policy application. The policy decisions are based on SLA metrics and BFD, so checking those is more direct. Packet capture would not show the policy's path selection logic.

Verify the WAN Edge's system IP is reachable by pinging the vSmart controller's system IP from the WAN Edge.

Why it fails: Pinging the vSmart system IP tests underlay reachability, but control connections use DTLS/TLS over the overlay and may be blocked by firewall rules even if ICMP succeeds. This step does not directly address why the DTLS/TLS session is stuck in 'connect' and could mislead the engineer into thinking the underlay is the only issue.

Verify that the WAN Edge has a valid certificate and that the root CA is installed.

Why it fails: While certificate issues can cause control connection failures, checking `show control local-properties` first is more appropriate because it reveals basic configuration errors. Certificate problems typically produce specific error messages in logs, and the 'connect' state alone does not confirm a certificate issue. This step is better after confirming basic parameters.

Restart the vSmart controller to force a new DTLS session with the WAN Edge.

Why it fails: Restarting the vSmart controller is disruptive and unlikely to resolve a configuration mismatch on the WAN Edge. If the WAN Edge has incorrect organization or controller IP settings, the session will still fail after restart. This action should be reserved for last-resort recovery and not used as a first diagnostic step.