OCI Network Path Analyzer: Troubleshooting Connectivity Without Guesswork

Network connectivity problems on OCI usually come down to a small set of causes. A route is missing, a security rule is blocking traffic, or a gateway is not where the traffic expects it to be. The trouble is that finding which one, across a network of subnets, route tables, security lists, and gateways, can turn into hours of manual checking. The OCI Network Path Analyzer exists to replace that manual hunt with a single answer. It traces the path traffic would take between two points and tells you exactly where it would succeed or fail. This guide explains what it does and how to use it.

The analyzer is a troubleshooting tool that sits across the whole network, so the pillar guide to OCI networking gives the context. It pairs naturally with the broader techniques in troubleshooting OCI networking, and it is most useful once you understand the routing hub in the DRG explained and the peering patterns in VCN peering.

What the Network Path Analyzer does

The Network Path Analyzer evaluates the configuration along a path between a source and a destination and reports whether traffic could flow. Crucially, it analyses configuration rather than sending live packets, so you can check a path before a workload even exists, or diagnose one that is failing, without generating real traffic. You give it a source, a destination, a protocol, and a port, and it walks the route tables, security lists, network security groups, and gateways in between, then tells you whether the path is reachable and, if not, exactly which element blocks it.

The paths it can analyse

The analyzer handles the common connectivity scenarios that cause trouble in real estates.

What it checks along the path

The value of the analyzer is that it inspects every layer that could break a connection, in the order traffic would meet them. It checks the route tables to confirm a route exists toward the destination. It checks the security lists and network security groups at both ends to confirm the traffic is permitted. It checks that the gateways the route depends on are present and attached. When any one of these blocks the path, the analyzer names it, which turns a vague report of cannot connect into a precise instruction about what to fix.

Using it to troubleshoot a live problem

When a connection is failing, the analyzer turns a guessing game into a procedure. Define the path that should work, run the analysis, and read where it fails. If it reports a missing route, fix the route table. If it reports a blocking security rule, adjust the rule. If it reports a missing gateway, attach it. Then run the analysis again to confirm the path is now clear. Because it analyses configuration rather than live traffic, you can iterate quickly without waiting for a real client to retry.

Using it before you deploy

The analyzer is just as useful proactively. Before you deploy a workload that needs to reach a database in another VCN or a service on premises, define the path and analyse it. If the configuration is wrong, you find out before the workload exists rather than during a go live. Building this check into your deployment process catches connectivity gaps early, when they are cheap to fix, instead of late, when they are blocking a release.

A troubleshooting framework

1. Define the exact path, source, destination, protocol, and port, that should work.
2. Run the Network Path Analyzer and read the first element it reports as blocking.
3. If a route is missing, correct the route table along the path.
4. If a security list or network security group blocks the traffic, adjust the rule at the right end.
5. If a required gateway is absent, attach it and add the route that points at it.
6. Run the analysis again to confirm the path is now reachable end to end.

Common mistakes the analyzer surfaces

• Traffic routed correctly but dropped by a security list or network security group at the destination.
• Missing routes across a DRG or peering, so traffic has no path even though security allows it.
• Asymmetric routing where traffic reaches the destination but the reply cannot return.
• A gateway that exists but is not referenced by any route table, so traffic never reaches it.

If your team spends too long chasing connectivity problems, our managed and monitoring engagements build path analysis into routine operations so issues are caught and resolved quickly. See the OCI monitoring service and the pillar guide to OCI networking for how it fits the wider picture.