Repository navigation
09 Networking ‐ Network Command Center
.
.
.
.
.
This lesson provided a high-level overview of Network Command Center, an OCI service that delivers a unified experience for all virtual network monitoring needs — giving you access to every tool from a single place for visualizing, monitoring, and troubleshooting your network. The tools covered include: Network Visualizer (interactive visualization of virtual network topology, showing resource interconnections and dependencies), Network Path Analyzer (identifies virtual network configuration issues by analyzing configured connectivity), Flow Logs (captures network traffic information for monitoring and security), the Inter-Region Latency Dashboard (provides a view of network health and metrics across all regions), Virtual Test Access Points (VTAP) (mirrors traffic from a designated source to a selected target for troubleshooting, security analysis, and data monitoring), and Capture Filter (a set of rules governing what traffic is captured by a VTAP or flow log). This was a 10,000-foot overview, with subsequent lessons diving into some of these services in greater detail.
Network Command Center is a tool (or service) that provides a unified experience for all your virtual network monitoring needs. It gives you access to all the tools from a single place.
These tools help you:
- Visualize your network
- Monitor your network
- Troubleshoot your network
Provides an interactive visualization of your virtual network topology, showing resource interconnections and dependencies.
Helps you identify virtual network configuration issues by analyzing the configured connectivity.
Helps you capture network traffic information that supports your monitoring and security needs.
Provides a view of network health and metrics for network service elements across all regions.
Allows you to mirror all traffic to or from a designated source and send it to a selected target. This facilitates:
- Troubleshooting
- Security analysis
- Data monitoring
Contains a set of rules governing what traffic is captured by a Virtual Test Access Point (VTAP) or a flow log.
This lesson explained the Inter-Region Latency Dashboard in OCI, a tool that reflects traffic flowing through the OCI backbone network — the global private IP network used for communication between regions. The dashboard displays the average inter-region round-trip latency for all pairs of regions in an OCI realm, helping customers make intelligent region selections for business expansion. It is not available in single-region realms, and the latency data is not specific to your tenancy's workloads — it provides general visibility to help plan data transfer and backups. The dashboard presents two charts: the Current Inter-Region Round-Trip Time (a real-time snapshot in milliseconds, averaged over the last five minutes and updated every minute — for example, Frankfurt to Ashburn at approximately 97.24 ms), and the Inter-Region Round-Trip Time historical view (covering the last 30 days, with selectable source and destination regions for validating network performance). The primary use cases include network planning (evaluating the performance impact of different regional selections, alongside factors like disaster recovery, compliance, and data residency), troubleshooting performance issues (validating real-time and historic performance), and monitoring integration (accessing latency data via the Monitoring API and integrating metrics into on-prem monitoring platforms to receive alerts when latency thresholds are exceeded).
In OCI, there is a concept called the OCI backbone network — the global private IP network that Oracle Cloud workloads use when communicating between different regions.
Inter-region latency reflects the traffic flowing through this backbone network.
The Inter-Region Latency Dashboard displays the average inter-region round-trip latency for all pairs of regions in an OCI realm.
Key points:
- This information helps customers make intelligent region selections for business expansion reasons.
- It is not available in realms that have only one region.
- The latency information provided is not specific to your tenancy's workloads — it provides visibility into latency between all regions to help you plan scenarios such as data transfer and backups.
The dashboard shows two charts:
- A current or real-time snapshot expressed in milliseconds.
- The snapshot is an average of values over the last five minutes.
- This view updates every minute.
Example: To determine the inter-region round-trip time between Germany Central (Frankfurt) and US East (Ashburn):
- Each cell displays the round-trip time in milliseconds, depending on the origin and destination pair.
- For Frankfurt → Ashburn, the latency is around 97.24 milliseconds.
- This value is based on the average over the past five minutes.
- Also expressed in milliseconds.
- Shows a historical view of the last 30 days.
- You choose the source and destination region, and the dashboard provides a historic snapshot of the last 30 days.
- This historical data can be used to validate network performance.
Region selection is influenced by many factors, including:
- Disaster recovery
- Compliance
- Data residency
- Performance
Using the Inter-Region Latency Dashboard, you can:
- Determine the performance impact of different regional selections.
- Make the optimal selection for your cloud deployment.
You can validate network performance — both real-time and historic — using the dashboard.
- Latency information is available through the Monitoring API.
- You can integrate metrics into your on-prem monitoring platform.
- This enables you to be notified whenever defined latency thresholds are exceeded.
This lesson introduced Network Path Analyzer, an OCI Command Center tool that identifies connectivity problems using automated configuration analysis of routing and security rules, along with queries to networking constructs to check reachability. It offers hop-by-hop path visualization and supports both bi-directional (forward and return path) and uni-directional analysis. Key features include precisely pinpointing routing and security configuration issues, supporting connectivity to the Oracle Services Network via service gateway or private endpoint, examining configuration instead of sending actual traffic to confirm reachability, and being completely free regardless of how many analyses you run. It supports scenarios spanning within OCI, OCI to on-premises, and OCI to internet. Two example scenarios illustrated its value: an OCI-to-OCI cross-VCN connection failing due to a misconfigured security list (status: unreachable), and an OCI-to-internet connection failing due to no route and a restrictive egress rule blocking access to Google Public DNS — both fixable by adjusting the relevant route and security rules. The primary use cases are troubleshooting routing and security misconfigurations (reducing MTTR for connectivity outages), on-demand validation of logical network paths (verifying connectivity works as intended before onboarding production applications, avoiding deployment delays), and proactive verification of routing and security policy configurations.
Network Path Analyzer is a Command Center tool that identifies connectivity problems.
It uses automated configuration analysis:
- Analyzes routing rules and security rules.
- Queries networking constructs to look for the configuration that allows it to check reachability.
- Provides hop-by-hop path visualization.
- Supports both bi-directional and uni-directional analysis.
- Bi-directional means both the forward and return path.
- Precisely points out routing and security configuration issues.
- Supports connectivity to the Oracle Services Network via service gateway or private endpoint.
- No actual traffic is sent — instead, the configuration is examined and used to confirm reachability.
- The service is free — it incurs no cost, no matter how many analyses you run.
- Supports different scenarios:
- Source and destination within OCI
- Across OCI and on-premises
- Across OCI and the internet
Two instances in different VCNs try to connect, with both VCNs connected to a Dynamic Routing Gateway (DRG) via VCN attachments.
- Problem: Traffic from the DRG and compute via the VCN to the attachment is denied.
- Cause: The security list is misconfigured.
- Result: Status shows unreachable.
Communication between OCI resources and internet resources is analyzed.
- Problem: No route is configured, and an egress rule is denying access to the Google Public DNS server.
- Fix: Quickly configure the required route and security rules to resolve the issue.
Identify misconfigurations causing connectivity issues — this significantly reduces the mean time to resolution (MTTR) for such outages.
Validate network paths to match intent and verify connectivity works as expected before onboarding production applications — avoiding delays in actual application deployment.
Users can proactively verify and validate network routing and security policy configurations.
This lesson introduced Network Visualizer, an OCI service that solves the challenge of understanding increasingly complex network architectures — where multiple VCNs, subnets, and gateways make manual visualization difficult. Network Visualizer provides a diagram of the implemented topology of all VCNs in a selected region and tenancy, allowing you to navigate quickly between core components such as hub and spoke VCNs, Dynamic Routing Gateways, remote peering connections, and on-premises connections. The service offers three levels of topology views: the Regional Topology Map (a high-level layout of the entire virtual network, including DRGs, VCNs, CPEs, and gateways), the VCN Topology Map (the organization of a single VCN, including its subnets and routing configuration), and the Subnet Topology (resources within a subnet such as instances, load balancers, and OKE clusters). Its primary use cases include visualizing and troubleshooting network security configuration issues (by showing relationships between security lists, NSGs, and other resources), understanding resource relationships and the impact of architectural changes, and getting an enhanced view of DRG attachments to troubleshoot transit routing configuration issues — making Network Visualizer a valuable tool for both design clarity and operational troubleshooting.
Consider a sample OCI network architecture. Inside an OCI region, there are two VCNs, along with different types of gateways:
- Service Gateway
- Local Peering Gateway
- Dynamic Routing Gateway
- Customer Premises Equipment (CPE) on the on-premises site
There are also different subnets, and inside those subnets, various resources such as:
- Virtual machines
- Database systems
- Object storage in the Oracle Services Network
While this example has only three VCNs, as more VCNs, subnets, and gateways are added, it becomes difficult to visualize the overall architecture. This is where Network Visualizer comes in.
Network Visualizer is a service that helps you visualize the whole network of any complexity very easily.
It provides a diagram of the implemented topology of all VCNs in a selected region and tenancy.
Example: In a hub-and-spoke topology, you can see:
- The spoke VCNs
- The hub VCN (connected to a Dynamic Routing Gateway)
- The remote peering connection
- The connection to your on-premises network
You can also navigate quickly between core components.
Network Visualizer lets you start with the regional topology and drill down to get more detail.
Provides a high-level layout of your entire virtual network configuration, including:
- Dynamic Routing Gateways
- VCNs
- Customer Premises Equipment
- Different types of gateways
Shows the organization of a single VCN, including:
- Its subnets
- The routing configuration
Shows information about resources in the subnet, such as:
- Instances
- Load balancers
- Services like OKE clusters
- See the relationship of security lists and NSGs (Network Security Groups) with other virtual network resources.
- Provides deeper insights to visualize relationships between resources.
- Helps you understand the impact of any change you make in the architecture.
- Get an enhanced view of Dynamic Routing Gateway attachments.
- Easily troubleshoot transit routing configuration issues.
This lesson explained capture filters, which are used with Flow Logs and VTAPs (Virtual Test Access Points) in Network Command Center Services to select which traffic to capture. Since capturing all network traffic can cause performance degradation, capture filters let you include only the required traffic. A capture filter is associated with a VTAP configuration (and a VTAP must have one), defines what traffic to capture, and must have at least one rule, up to a maximum of 10. Rules are examined in order and executed when matched — once a match is found, remaining rules are skipped for that packet, which makes the ordering of rules critically important, as reordering changes the filter's behavior. Rules can include or exclude traffic based on source/destination CIDR, protocol, source/destination port, and traffic direction (ingress/egress); if a rule omits a CIDR or protocol, all IPs/protocols are accepted for that rule. An example showed a VTAP with a load balancer source and network load balancer target, using a capture filter to identify anomalous web traffic by filtering ingress HTTP traffic (source CIDR 0.0.0.0, destination Subnet A, TCP, port 80). A detailed example demonstrated the importance of rule ordering: to capture all traffic from 10.1.0.0/16 except 10.1.1.1, the Exclude rule for 10.1.1.1/32 must come first — if it's moved later, the packet matches an earlier Include rule, gets mirrored, and the Exclude rule is never evaluated, defeating the purpose. Understanding rule sequence is therefore essential for correct capture filter behavior.
Within Network Command Center Services, there are two key features:
- Flow Logs
- VTAP (Virtual Test Access Points)
When using either flow logs or VTAPs, you can use capture filters to select which traffic to include in either the flow logs or VTAP.
As the name suggests, a capture filter is a filter — you decide what type of traffic to capture.
Capturing all traffic flowing through the network can sometimes cause performance degradation.
Therefore, capture filters let you include only the required traffic in flow logs or VTAP.
- A capture filter is associated with a VTAP configuration.
- It defines what type of traffic to capture.
- A VTAP must have a capture filter associated with it.
- Each capture filter must have at least one rule.
- It can have up to 10 rules.
- Capture filter rules are examined in order and executed when matched.
- When a match is found, the remaining rules are not examined or executed on that packet.
- Therefore, the ordering of rules is critical — reordering rules changes the capture filter's behavior.
In the console, you can create capture filter rules with:
- Actions: Include or Exclude
-
Criteria:
- Source and destination CIDR
- Protocol
- Source and destination port
- Traffic direction setting: Captures traffic based on ingress or egress criteria
Note: If a rule doesn't specify a CIDR block/prefix or IP protocol, all IP addresses or IP protocols are accepted for that rule.
In the example shown:
- VTAP source: A load balancer distributing web traffic to back-end web servers (in Subnet A).
- VTAP target: A network load balancer.
- Capture filter purpose: Filter ingress HTTP traffic coming to the load balancer from the internet, to identify anomalous web traffic.
Rule defined:
| Setting | Value |
|---|---|
| Traffic direction | Ingress |
| Source CIDR | 0.0.0.0 (internet) |
| Destination CIDR | Subnet A |
| IP protocol | TCP |
| Destination port | 80 |
This means: ingress HTTP traffic.
Goal: Capture all traffic from CIDR 10.1.0.0/16 except 10.1.1.1.
| Rule # | Source CIDR | Action |
|---|---|---|
| 1 | 10.1.1.1/32 |
Exclude |
| 2+ | Other include rules | Include |
What happens:
- A packet from
10.1.1.1matches Rule 1 → excluded from mirrored traffic. - Other packets continue to be evaluated against subsequent rules.
Result: Works as intended.
| Rule # | Source CIDR | Action |
|---|---|---|
| 1 | Other include rules | Include |
| 3 | 10.1.1.1/32 |
Exclude |
What happens:
- A packet from
10.1.1.1matches Rule 1 → included in mirrored traffic. - Since a match was found, Rule 3 is never evaluated.
- The further rule evaluations are skipped.
Result: Does not serve the purpose — the packet is included when it should have been excluded.
Key takeaway: Because rules are evaluated in order and processing stops at the first match, the sequence of rules is critical to achieving the desired filtering behavior.
This lesson introduced Virtual Test Access Points (VTAP) in OCI, which mirror traffic from a designated source to a selected target to enable troubleshooting, security analysis, and data monitoring. When multiple VTAPs have overlapping source configurations, the traffic from the VTAP with the more specific source is mirrored. A VTAP consists of three components: the VTAP source (the monitored resource), the VTAP target (where mirrored traffic is sent), and capture filter rules (which select what traffic is mirrored). The source and target must reside in the same VCN. In a typical scenario, a VM in one subnet sends traffic, a VTAP monitors traffic leaving that VM, and the traffic matching the capture filter is mirrored to a Network Load Balancer in another subnet, where the backend set performs analysis. The mirrored traffic is encapsulated in VxLAN and delivered to the target via UDP port 4789. VTAP sources can include compute instance VNICs, load balancers, database systems, Exadata VM clusters, and Autonomous Databases, while the target must be a Network Load Balancer with a UDP listener on port 4789 in the same VCN. Key use cases include deep packet inspection for detecting anomalous behavior, compliance logging and monitoring, and troubleshooting application performance issues.
A Virtual Test Access Point (VTAP) provides a way to mirror traffic from a designated source to a selected target to facilitate:
- Troubleshooting
- Security analysis
- Data monitoring
Note: If you have multiple VTAPs with an overlapping source configuration, the traffic from the VTAP with the more specific source will be mirrored.
- VTAP Source — The resource that the VTAP monitors. The traffic on this resource is mirrored and sent to a chosen target.
- VTAP Target — Receives the mirrored traffic.
Important: The VTAP source and target must be hosted in the same VCN.
Each VTAP consists of three components:
- VTAP Source — The resource being monitored.
- VTAP Target — Where the mirrored traffic is sent.
- Capture Filter Rules — Select what is included in the traffic that is mirrored from the source to the target.
In the example:
- A virtual machine in Subnet A sends traffic to another virtual machine in Subnet B.
- A VTAP in Subnet A checks traffic leaving the virtual machine.
- Because this traffic matches the capture filter, the VTAP mirrors the traffic to the target.
- The target is a Network Load Balancer deployed in Subnet C.
- The backend set can then perform appropriate analysis on the mirrored traffic.
The mirrored traffic is encapsulated in VxLAN and sent to the VTAP target (the Network Load Balancer) via UDP port 4789.
The VTAP source can be:
- A single compute instance VNIC in a subnet
- A load balancer
- A database system
- An Exadata VM cluster
- An Autonomous Database
- Must be a Network Load Balancer with a UDP listener on port 4789.
- Must be in the same VCN as the VTAP source.
- The backend set performs the appropriate analysis on the mirrored traffic.
Detect anomalous behavior.
Meet mandates to log and monitor traffic.
Identify issues impacting application performance.