Network Path Analyzer (NPA) provides a unified and intuitive capability you can use to identify virtual network configuration issues that impact connectivity. NPA collects and analyzes the network configuration to determine how the paths between the source and the destination function or fail. No actual traffic is sent, instead the configuration is examined and used to confirm reachability.
NPA carefully examines routing and security configurations and identifies the potential
network path your defined traffic traverses, along with information about virtual networking
entities in the path. In addition to the path information, output of these checks includes
how routing rules and network access lists (security lists, NSGs, and so on) allow or deny
traffic. The sources and destinations could be within OCI, or across OCI and on-premises, or
OCI and internet. NPA analyzes all the standard OCI networking elements with their
associated configuration.
Using NPA, you can:
Troubleshoot routing and security misconfigurations that are causing connectivity
issues
Validate that the logical network paths match your intent
Verify that the virtual network connectivity setup works as expected before starting to
send traffic
To achieve any of these objectives, create a test that you think should work and then run the test. You can also save this test definition to run it again later. Saved tests are displayed in the Network Path Analyzer page for you to select.
The following source and destination scenarios are supported:
OCI to OCI
OCI to on-premises
On-premises to OCI
Internet to OCI
OCI to internet
Tests can be defined for the following parameters:
Source options
Destination options
Protocol
Port Information
Bi-directional flag
An IP address (within OCI, on-premises or internet)
Compute instance VNIC
LBaaS
NLB
An IP address (within OCI, on-premises or internet)
Compute instance VNIC
LBaaS
NLB
Any IP protocol supported in the current security list.
Depending on the protocol type provided:
Destination port
Source port
ICMP options
A bidirectional check flag, enabled by default for TCP and UDP. You have the
flexibility to turn off this flag to check unidirectional connectivity and path
(source to destination). This flag is disabled for non- TCP/UDP protocols.
An analysis is done using a full configuration snapshot, but the resulting network path
displayed is limited to the entities that you have permission to view. When you do not have
the needed permission to view objects in the path, the test output does not show those
objects or any further details.
Network Path Analyzer uses Batfish, an open source network configuration analysis library. NPA uses Batfish to perform reachability analysis and identify configuration errors. Intentionet maintains the Batfish library.
Required Permissions 🔗
Oracle recommends that you always set the following permissions policies at the tenancy level (setting these permissions at a compartment level can make the path analysis results less accurate) to use Network Path Analyzer:
Copy
allow group <group-name> to manage vn-path-analyzer-test in tenancy
allow any-user to inspect compartments in tenancy where all { request.principal.type = 'vnpa-service' }
allow any-user to read instances in tenancy where all { request.principal.type = 'vnpa-service' }
allow any-user to read virtual-network-family in tenancy where all { request.principal.type = 'vnpa-service' }
allow any-user to read load-balancers in tenancy where all { request.principal.type = 'vnpa-service' }
allow any-user to read network-security-group in tenancy where all { request.principal.type = 'vnpa-service' }
Where <group-name> is the name of the administrator group for
networking resources.
Note
Granting permissions to use this tool might lead to overexposure of
information about network configuration and network security settings to a user of the tool.
Observing reachability status can be used by a malicious user to infer the presence of
network services and related routing and security information. Access to the tool should be
given only to trusted users and administrators.
Source and destinations that are within the same subnet and with a different Private IP
will produce incorrect results.
When a subnet's route table has a next-hop defined as a private IP, it might incorrectly
show the status as No-Route.
If LPGs are peered across tenancies, the response for the Path Analysis is
Indeterminate.
If RPC connections cross tenancies or regions, the response for the Path Analysis is
Indeterminate.
NPA does not support IPv6. IPv6 addresses cannot be used as sources or destinations. IPv6 routing and security settings are ignored and do not affect the results.
NPA does not detect routing loops, and if routing loops are present the results can be inconclusive or indicate a failure.
Intra-VCN routing and internet gateway routing are not yet supported in NPA and can cause inaccurate Path Analysis results.
Currently NPA will not function if the number of compartments in the tenancy requesting the Path Analysis is more than 100. For these tenancies you must raise a support request to use NPA.
Special use cases
When some entities are in the path for a path analysis and they are neither the source or
the destination, the following behaviors are seen. You can use the indicated solution for
these use cases, if one is available.
Node in Path
NPA Outcome
Solution
Network Virtual Appliance (NVA)
Indeterminate
Create two Path Analysis checks, one from the source to the NVA and one from the NVA
to the destination.
NLB deployed in non-transparent mode with SNAT configured
No Route
Create two Path Analysis checks, one from the source to the NLB and one from the NLB
to the destination.
Network Load Balancer in transparent mode
Indeterminate
Create two Path Analysis checks, one from the source to the NLB and one from the NLB
to the destination.
Load Balancer
No Route
Create two Path Analysis checks, one from the source to the LB and one from the LB to
the destination.
FWaaS
Indeterminate
Create two Path Analysis checks, one from the source to the FWaaS and one from the
FWaaS to the destination.
Cross-region using RPC
Indeterminate
Create two Path Analysis checks, one for each region.
Cross-tenancy using LPG
Indeterminate
Create two Path Analysis checks, one for each tenancy.
DRG v1
Indeterminate
Upgrade to DRG v2.
The following diagram shows one of the use cases where the path analysis must be split in
two.
Network Path Analysis Work Requests
Work requests allow you to monitor long-running operations like network path analysis tests. When you launch such an operation, the service spawns a work request . A work request is an activity log that enables you to track each step in the operation's progress. Each work request has an OCID (Oracle Cloud Identifier) that allows you to interact with it programmatically and use it for automation. Work requests are retained for 12 hours.
Network Path Analyzer Tasks 🔗
You can perform the following tasks using the Network Path Analyzer tool: