09 Networking ‐ Network Command Center - KleberVales/OCI-Architect-Associate GitHub Wiki

1. Network Command Center Overview

1.1 What Is Network Command Center?

1.2 Tools Within Network Command Center

2. Inter-Region Latency

2.1 The OCI Backbone Network

2.2 What Is the Inter-Region Latency Dashboard?

2.3 The Two Charts

2.4 Use Cases

3. Network Path Analyzer

3.1 What Is Network Path Analyzer?

3.2 Features

3.3 Example Scenarios

3.4 Use Cases

4. Network Visualizer

4.1 The Challenge: Visualizing Complex Networks

4.2 What Is Network Visualizer?

4.3 The Three Topology Levels

4.4 Use Cases

5. Capture filters

5.1 What Are Capture Filters?

5.2 Why Use Capture Filters?

5.3 Key Rules and Behavior

5.4 Rule Configuration Options

5.5 Example: Filtering Ingress HTTP Traffic

5.6 Understanding Rule Ordering: A Detailed Example

6. Virtual Test Access Points

6.1 What Is a VTAP?

6.2 VTAP Source and Target

6.3 Components of a VTAP

6.4 Example Scenario

6.5 How Traffic Is Encapsulated

.
.
.
.
.

1. Network Command Center Overview

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.

1.1 What Is Network Command Center?

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

1.2 Tools Within Network Command Center

1. Network Visualizer

Provides an interactive visualization of your virtual network topology, showing resource interconnections and dependencies.

2. Network Path Analyzer

Helps you identify virtual network configuration issues by analyzing the configured connectivity.

3. Flow Logs

Helps you capture network traffic information that supports your monitoring and security needs.

4. Inter-Region Latency Dashboard

Provides a view of network health and metrics for network service elements across all regions.

5. Virtual Test Access Points (VTAP)

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

6. Capture Filter

Contains a set of rules governing what traffic is captured by a Virtual Test Access Point (VTAP) or a flow log.

2. Inter-Region Latency

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).

2.1 The OCI Backbone Network

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.

2.2 What Is the Inter-Region Latency Dashboard?

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.

2.3 The Two Charts

The dashboard shows two charts:

Chart 1: Current Inter-Region Round-Trip Time

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.

Chart 2: Inter-Region Round-Trip Time (Historical)

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.

2.4 Use Cases

1. Network Planning

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.

2. Troubleshooting Performance Issues

You can validate network performance — both real-time and historic — using the dashboard.

3. Monitoring Integration

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.

3. Network Path Analyzer

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.

3.1 What Is Network Path Analyzer?

Network Path Analyzer is a Command Center tool that identifies connectivity problems.

How It Works

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.

Key Capabilities

Provides hop-by-hop path visualization.
Supports both bi-directional and uni-directional analysis.
- Bi-directional means both the forward and return path.

3.2 Features

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

3.3 Example Scenarios

Scenario 1: OCI-to-OCI (Across VCNs)

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.

Scenario 2: OCI-to-Internet

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.

3.4 Use Cases

1. Troubleshooting Routing and Security Misconfigurations

Identify misconfigurations causing connectivity issues — this significantly reduces the mean time to resolution (MTTR) for such outages.

2. On-Demand Validation of Logical Network Paths

Validate network paths to match intent and verify connectivity works as expected before onboarding production applications — avoiding delays in actual application deployment.

3. Proactive Verification

Users can proactively verify and validate network routing and security policy configurations.

4. Network Visualizer

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.

4.1 The Challenge: Visualizing Complex Networks

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.

4.2 What Is Network Visualizer?

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.

4.3 The Three Topology Levels

Network Visualizer lets you start with the regional topology and drill down to get more detail.

1. Regional Topology Map

Provides a high-level layout of your entire virtual network configuration, including:

Dynamic Routing Gateways
VCNs
Customer Premises Equipment
Different types of gateways

2. VCN Topology Map

Shows the organization of a single VCN, including:

Its subnets
The routing configuration

3. Subnet Topology

Shows information about resources in the subnet, such as:

Instances
Load balancers
Services like OKE clusters

4.4 Use Cases

1. Visualize and Troubleshoot Network Security Configuration Issues

See the relationship of security lists and NSGs (Network Security Groups) with other virtual network resources.

2. Understand Resource Relationships and Change Impact

Provides deeper insights to visualize relationships between resources.
Helps you understand the impact of any change you make in the architecture.

3. Enhanced View of DRG Attachments

Get an enhanced view of Dynamic Routing Gateway attachments.
Easily troubleshoot transit routing configuration issues.

5. Capture filters

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.

5.1 What Are Capture Filters?

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.

5.2 Why Use Capture Filters?

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.

5.3 Key Rules and Behavior

Association with 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.

Number of Rules

Each capture filter must have at least one rule.
It can have up to 10 rules.

Rule Processing Order

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.

5.4 Rule Configuration Options

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.

5.5 Example: Filtering Ingress HTTP Traffic

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.

5.6 Understanding Rule Ordering: A Detailed Example

Goal: Capture all traffic from CIDR 10.1.0.0/16 except 10.1.1.1.

Approach 1: Correct Ordering ✓

Rule #	Source CIDR	Action
1	`10.1.1.1/32`	Exclude
2+	Other include rules	Include

What happens:

A packet from 10.1.1.1 matches Rule 1 → excluded from mirrored traffic.
Other packets continue to be evaluated against subsequent rules.

Result: Works as intended.

Approach 2: Incorrect Ordering ✗

Rule #	Source CIDR	Action
1	Other include rules	Include
3	`10.1.1.1/32`	Exclude

What happens:

A packet from 10.1.1.1 matches 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.

6. Virtual Test Access Points

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.

6.1 What Is a VTAP?

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.

6.2 VTAP Source and Target

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.

6.3 Components of a VTAP

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.

6.4 Example Scenario

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.

6.5 How Traffic Is Encapsulated

The mirrored traffic is encapsulated in VxLAN and sent to the VTAP target (the Network Load Balancer) via UDP port 4789.

VTAP Sources

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

VTAP Target Requirements

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.

Use Cases

1. Deep Packet Inspection

Detect anomalous behavior.

2. Compliance

Meet mandates to log and monitor traffic.

3. Troubleshooting

Identify issues impacting application performance.