OCI FastConnect to Azure ExpressRoute — Complete Step-by-Step Practical Lab

1. Lab Objective

The objective of this lab was to establish private network connectivity between Oracle Cloud Infrastructure (OCI) and Microsoft Azure using the Oracle–Azure Native Interconnect.

In this lab, I configured the Azure network, ExpressRoute circuit, ExpressRoute gateway, and gateway connection. On the OCI side, I configured FastConnect, BGP peering, the Dynamic Routing Gateway (DRG), and network routing.

I also configured the required security rules and firewall settings on both sides. Finally, I tested connectivity by pinging the Azure VM's private IP from OCI and the OCI instance's private IP from Azure. Both ping tests were successful.

2. Lab Architecture

3. Lab Architecture and IP Address Plan

3.1 OCI Configuration

Resource	Configuration
Region	US East (Ashburn), us-ashburn-1
Compute instance	bastion-server
OCI private IP	10.0.0.91
Workload subnet	10.0.0.0/25
Recorded subnet gateway	10.0.0.1
Connectivity	FastConnect
Routing component	Dynamic Routing Gateway (DRG)
Routing protocol	BGP

3.2 Azure Configuration

Resource	Configuration
Subscription	Azure subscription 1
Resource group	OCI-Azure-Migration-RG
Region	East US
Virtual network	Azure-Hub-VNet
Workload subnet	Workload-Subnet
Workload subnet CIDR	10.10.1.0/24
Gateway subnet	GatewaySubnet
Gateway subnet CIDR	10.10.255.0/27
Test VM	Azure-Test-VM
Azure VM private IP	10.10.1.4
Network Security Group	Azure-Test-VM-nsg
ExpressRoute circuit	OCI-Azure-ExpressRoute
ExpressRoute gateway	Azure-ExpressRoute-Gateway
Gateway connection	OCI-Azure-Gateway-Connection1

Note: Verify the complete Azure VNet address space in the portal before reusing this lab. The workload and gateway subnet CIDRs above are the recorded values for this lab.

3.3 Why Must the CIDR Ranges Not Overlap?

The OCI and Azure workload networks use different IP ranges:

• OCI workload subnet: 10.0.0.0/25
• Azure workload subnet: 10.10.1.0/24

These ranges do not overlap. Non-overlapping CIDR ranges allow the routing components to identify the correct destination network when traffic travels between the two clouds.

3.4 BGP Peering IP Address Plan

The following IPv4 addresses were configured for the FastConnect BGP peering sessions.

Field	IP address
Customer primary BGP IPv4	192.168.100.2/30
Oracle primary BGP IPv4	192.168.100.1/30
Customer secondary BGP IPv4	192.168.100.6/30
Oracle secondary BGP IPv4	192.168.100.5/30

These are transit addresses used for BGP peering. They are not the private IP addresses of the OCI or Azure VMs.

Why Did I Use /30?

A /30 IPv4 subnet contains four addresses: one network address, two usable host addresses, and one broadcast address.

Example primary peering subnet:

Address	Purpose
192.168.100.0	Network address
192.168.100.1	Oracle-side BGP address
192.168.100.2	Customer/Azure-side BGP address
192.168.100.3	Broadcast address

The secondary peering uses 192.168.100.4/30, with Oracle using 192.168.100.5 and the customer/Azure side using 192.168.100.6.

This provides two separate point-to-point IPv4 peering subnets, each with two usable addresses.

Important: The customer and Oracle IP assignments, ASN values, and subnet masks must match the actual interconnect configuration. Do not copy ASN values from another lab without checking the configured values.

---

4. Step 1 — Sign In to the Azure Portal

1. Open the Azure portal: https://portal.azure.com
2. Sign in using your Microsoft account.
3. Select the existing subscription named Azure subscription 1.
4. Verify that the subscription is active.
5. Check the available credits and billing information before creating resources.

Note: I selected an existing subscription; I did not create a new Azure subscription during this lab.

Azure credits do not automatically guarantee that ExpressRoute, gateway, or other networking services are free.

5. Step 2 — Create the Azure Resource Group

A resource group is a logical container for Azure resources.

1. Search for Resource groups.
2. Click Create.
3. Select the subscription Azure subscription 1.
4. Enter the resource group name: OCI-Azure-Migration-RG.
5. Select the region East US.
6. Click Review + create.
7. Click Create.
8. Open the resource group after deployment.

I used this resource group to organize the Azure resources created for the lab.

6. Step 3 — Create the Azure Virtual Network

A Virtual Network (VNet) provides private network connectivity for Azure resources.

1. Search for Virtual networks.
2. Click Create.
3. Select the resource group OCI-Azure-Migration-RG.
4. Enter the VNet name Azure-Hub-VNet.
5. Select the region East US.
6. Configure an address space that does not overlap with the OCI network.
7. Create the VNet.

Create the Workload Subnet

1. Open Azure-Hub-VNet.
2. Select Subnets.
3. Click + Subnet.
4. Enter the subnet name Workload-Subnet.
5. Enter the recorded CIDR 10.10.1.0/24.
6. Save the subnet.

This subnet hosts the Azure test VM.

7. Step 4 — Create the Azure Test VM

The Azure VM is the workload endpoint used to test private connectivity.

1. Search for Virtual machines.
2. Click Create → Azure virtual machine.
3. Select the resource group OCI-Azure-Migration-RG.
4. Enter the VM name Azure-Test-VM.
5. Select the region East US.
6. Select a supported Linux image and an appropriate VM size.
7. Configure authentication using a supported method.
8. Under Networking, select:
   • Virtual network: Azure-Hub-VNet
   • Subnet: Workload-Subnet
9. Configure a public IP only if required for administration.
10. Review the estimated cost.
11. Click Review + create, then Create.
12. Wait for deployment to complete.
13. Open the VM and check its networking details.

The recorded private IP address was 10.10.1.4.

Record the VM private IP, network interface (NIC), subnet, Network Security Group (NSG), operating system, and VNet name.

The cross-cloud connectivity test uses the private IP address, not the VM's public IP address.

8. Step 5 — Configure the Azure Network Security Group

A Network Security Group controls permitted network traffic. The NSG used in this lab was Azure-Test-VM-nsg.

Verify the NSG Association

1. Open Azure-Test-VM.
2. Select Networking.
3. Open the VM's network interface.
4. Check the Network Security Group association.
5. Confirm that Azure-Test-VM-nsg is associated with the NIC.

The recorded NSG overview showed zero associated subnets and one associated network interface. Therefore, the NSG was attached to the VM's NIC rather than directly to the subnet.

Add an Inbound ICMP Rule

1. Open Azure-Test-VM-nsg.
2. Select Inbound security rules.
3. Click Add.
4. Configure the rule to allow ICMP traffic from the OCI test instance.

Setting	Value
Name	Allow-ICMP-From-OCI
Priority	310
Source	IP Addresses
Source IP	10.0.0.91/32
Destination	Azure VM or its private IP
Destination port ranges	*
Protocol	ICMP, if available
Action	Allow

The /32 source range restricts this rule to the OCI test instance's private IP.

Important: Verify the final rule in the Azure portal. The recorded initial source range was 10.0.0.0/25, while the /32 range above is the narrower rule for the specific test VM. Use the actual final configuration shown in your screenshots.

If ICMP is not available as a selectable protocol in the portal, check the supported rule options rather than assuming that allowing TCP or UDP also permits ICMP.

9. Step 6 — Create the Azure GatewaySubnet

An ExpressRoute virtual network gateway requires a dedicated subnet named exactly GatewaySubnet.

Why is a separate subnet required?

Azure reserves this subnet for the virtual network gateway. Workload VMs must not be deployed into it.

Create the GatewaySubnet

1. Open Azure-Hub-VNet.
2. Select Subnets.
3. Click + Subnet.
4. Enter the name GatewaySubnet.
5. Enter the recorded CIDR 10.10.255.0/27.
6. Save the subnet.

Verify the Subnet

• The name must be exactly GatewaySubnet.
• The subnet must belong to Azure-Hub-VNet.
• Its CIDR must not overlap with the workload subnet.
• The CIDR must be within the VNet address space and satisfy Azure's gateway subnet requirements.
• Do not deploy workload VMs into this subnet.

10. Step 7 — Create the Azure ExpressRoute Circuit

An ExpressRoute circuit provides the Azure-side connection to the supported connectivity provider. The circuit configured in this lab was OCI-Azure-ExpressRoute.

Create the Circuit

1. Search for ExpressRoute circuits.
2. Click Create.
3. Select the resource group OCI-Azure-Migration-RG.
4. Enter the circuit name OCI-Azure-ExpressRoute.
5. Select the required region and supported peering location.
6. Select the provider Oracle Cloud FastConnect, where available.
7. Configure the circuit according to the supported service options.
8. Review the bandwidth, SKU, resiliency, and billing details.
9. Click Review + create.
10. Click Create.
11. Wait for deployment to complete.
12. Open the circuit and check its overview.

Recorded Circuit Details

Setting	Recorded value
Circuit name	OCI-Azure-ExpressRoute
Provider	Oracle Cloud FastConnect
Peering location	Washington DC
Bandwidth	1000 Mbps (1 Gbps)
SKU	Local
Billing model	Unlimited
Resiliency	Standard
Circuit status	Enabled
Provider status	Provisioned

The circuit status and provider status are separate fields.

Important: Creating an ExpressRoute resource does not automatically prove that end-to-end private connectivity is working. The provider-side interconnect, BGP, routing, and security configuration must also be correct.

11. Step 8 — Configure the ExpressRoute BGP Peering

BGP stands for Border Gateway Protocol. It exchanges network routes between connected networks.

Open the Peering Configuration

1. Open OCI-Azure-ExpressRoute.
2. Select Peerings.
3. Open the appropriate private peering configuration.
4. Review the IPv4 peering settings.
5. Configure the BGP IP addresses and ASN values according to the actual interconnect setup.

BGP IPv4 Configuration

Field	Value
Customer primary BGP IPv4	192.168.100.2/30
Oracle primary BGP IPv4	192.168.100.1/30
Customer secondary BGP IPv4	192.168.100.6/30
Oracle secondary BGP IPv4	192.168.100.5/30

The primary and secondary sessions use separate /30 peering subnets.

Configure the ASN Values

The local and remote Autonomous System Numbers (ASNs) must match the actual service configuration. Check the configured values in the Azure peering settings and the OCI FastConnect configuration.

Do not assume an ASN value from another lab.

Save and Verify

1. Save the peering configuration.
2. Open the peering status.
3. Check whether BGP is established.
4. Review advertised and learned routes where available.

Recorded result: The IPv4 BGP session was reported as Up in OCI. The Azure private peering was shown as Provisioned.

These statuses are useful checkpoints, but the actual route exchange must still be verified.

12. Step 9 — Create the Azure ExpressRoute Virtual Network Gateway

The virtual network gateway connects the Azure VNet to the ExpressRoute circuit.

Create the Gateway

1. Search for Virtual network gateways.
2. Click Create.
3. Select the resource group OCI-Azure-Migration-RG.
4. Enter the name Azure-ExpressRoute-Gateway.
5. Select the region matching the VNet.
6. Set the gateway type to ExpressRoute.
7. Select a supported gateway SKU.
8. Select the VNet Azure-Hub-VNet.
9. Select the previously created GatewaySubnet.
10. Configure the required gateway settings.
11. Review the estimated cost.
12. Click Review + create.
13. Click Create.
14. Wait for the deployment to complete.

Verify the Gateway

Open Azure-ExpressRoute-Gateway and confirm:

• Provisioning state is successful.
• Gateway type is ExpressRoute.
• The correct VNet is selected.
• The gateway uses the correct GatewaySubnet.

Note: Gateway deployment can take a significant amount of time. The gateway and ExpressRoute circuit are separate resources.

13. Step 10 — Create the Gateway Connection

The ExpressRoute circuit and Azure virtual network gateway must be connected using an Azure connection resource.

Create the Connection

1. Open the ExpressRoute circuit OCI-Azure-ExpressRoute.
2. Select Connections.
3. Click Create connection.
4. Select the subscription Azure subscription 1.
5. Select the resource group OCI-Azure-Migration-RG.
6. Set the connection type to ExpressRoute.
7. Under Settings, select:
   • Virtual network gateway: Azure-ExpressRoute-Gateway
   • ExpressRoute circuit: OCI-Azure-ExpressRoute
8. Select Standard Resiliency for this lab.
9. Enter the connection name OCI-Azure-Gateway-Connection1.
10. Leave Redeem ExpressRoute authorization disabled unless the actual configuration requires it.
11. Keep Routing weight at its default value.
12. Keep FastPath disabled for this lab.
13. Under Monitoring, disable Connection Monitor because monitoring is not required for the basic ping test.
14. Leave Tags empty if not required.
15. Click Review + create.
16. Confirm that validation passes.
17. Click Create.
18. Wait for deployment to complete.

Why Did I Select Standard Resiliency?

Standard Resiliency provides physical link redundancy within one peering location. Maximum Resiliency can require circuits across multiple distinct edge locations. For this lab, I selected Standard rather than configuring additional circuits.

Important: Resiliency options and the required number of circuits depend on the service design. Selecting Standard does not remove ExpressRoute or gateway charges.

Verify the Connection

Open the connection and check its status.

Recorded connection name: OCI-Azure-Gateway-Connection1

A successful connection resource is a checkpoint. It does not, by itself, prove that the workload routes and firewalls are correct.

14. Step 11 — Configure OCI Networking

The OCI side requires a workload VCN and subnet, route table, DRG, FastConnect virtual circuit, and the correct security rules.

14.1 Sign In to OCI

1. Open the OCI Console.
2. Sign in to your tenancy.
3. Select the Ashburn region us-ashburn-1.
4. Open the compartment containing the OCI network and test instance.

14.2 Verify the OCI Workload Subnet

The recorded OCI workload subnet was 10.0.0.0/25.

The test instance details were:

• Instance name: bastion-server
• Private IP: 10.0.0.91
• Recorded subnet gateway: 10.0.0.1

Open the VCN and subnet and verify the subnet CIDR, route table association, security configuration, instance private IP, VCN, and compartment.

14.3 Create or Verify the DRG

The Dynamic Routing Gateway (DRG) is the OCI routing component used for connections to external networks.

1. Open Networking in the OCI Console.
2. Navigate to Customer connectivity → Dynamic routing gateways, or the equivalent navigation in your console.
3. Select the correct compartment.
4. Create a DRG if a suitable DRG does not already exist.
5. Enter a meaningful name.
6. Create the DRG.
7. Wait until its lifecycle state is Available.

If a suitable DRG already exists, verify it rather than creating a duplicate.

14.4 Attach the DRG to the VCN

1. Open the DRG.
2. Open its attachments.
3. Create a VCN attachment if one does not already exist.
4. Select the VCN containing the workload subnet.
5. Save the attachment.
6. Wait for the attachment to become available.

The VCN attachment connects the VCN routing domain to the DRG.

15. Step 12 — Create or Verify the OCI FastConnect Virtual Circuit

FastConnect provides private connectivity through a supported connectivity provider.

Create or Verify FastConnect

1. Open Networking → Customer connectivity → FastConnect.
2. Select the correct compartment.
3. Choose the supported Oracle–Azure Native Interconnect or provider-backed configuration available for the tenancy and region.
4. Select or associate the appropriate DRG.
5. Configure the provider and circuit details.
6. Configure the primary and secondary BGP peering information.
7. Enter the required ASN values.
8. Save or submit the configuration.
9. Wait for provisioning to complete.

If the correct virtual circuit already exists, verify it rather than creating another one.

Verify the BGP Values

OCI FastConnect field	Value
Customer primary BGP IPv4	192.168.100.2/30
Oracle primary BGP IPv4	192.168.100.1/30
Customer secondary BGP IPv4	192.168.100.6/30
Oracle secondary BGP IPv4	192.168.100.5/30

Enter the values only in their matching fields. The customer and Oracle address assignments must agree with the actual provider configuration.

Verify the Circuit State

Open the FastConnect virtual circuit and check its lifecycle state, IPv4 BGP state, primary and secondary peering configuration, DRG association, and available routing information.

Recorded result: The OCI FastConnect virtual circuit was Provisioned, and its IPv4 BGP state was Up.

IPv6 was not required for this IPv4 ping lab.

Important: Creating a DRG does not automatically create a working FastConnect connection. Provider provisioning, BGP, DRG attachments, route configuration, and security rules must all be correct.

16. Step 13 — Configure the OCI Route Table

The OCI workload subnet needs a route toward the Azure workload network.

Add or Verify the Route Rule

1. Open the OCI VCN.
2. Select Route Tables.
3. Open the route table associated with the workload subnet.
4. Review the existing route rules.
5. Add or verify the route to the Azure workload subnet.

Setting	Value
Destination type	CIDR Block
Destination CIDR	10.10.1.0/24
Target type	Dynamic Routing Gateway
Target	DRG attached to the workload VCN

Save the route rule.

Why Is This Route Needed?

When bastion-server sends traffic to 10.10.1.4, OCI must know that the destination is reachable through the DRG and the interconnect.

Without a valid route, the traffic might not reach the Azure network.

Important: A route rule alone does not prove that the remote route is advertised or that the interconnect is working.

17. Step 14 — Verify the Azure Return Route

Network communication requires a valid route in both directions.

When the Azure VM receives a ping from OCI, its reply must return to the OCI private IP.

• OCI source IP: 10.0.0.91
• Recorded OCI workload subnet: 10.0.0.0/25

Verify Azure Routing

1. Open Azure-Hub-VNet.
2. Check any route tables associated with the workload subnet or VM NIC.
3. Open the Azure VM's NIC and inspect effective routes where available.
4. Review the ExpressRoute learned routes where available.
5. Confirm that the OCI prefix is reachable through the ExpressRoute gateway.
6. Check whether any user-defined route overrides the expected route.

The return route must match the OCI prefix actually advertised through BGP.

Verify OCI Routing

Where available, inspect:

• OCI VCN route table rules.
• DRG route tables.
• DRG route distributions.
• BGP learned and advertised routes.

Important: Do not add an arbitrary static route using an invented next-hop IP. Use the routing model supported by the actual DRG and interconnect configuration.

18. Step 15 — Configure OCI Security Rules

OCI security rules control whether the workload can receive traffic from Azure. The relevant security configuration may be a Security List, an NSG, or both.

Add an Inbound ICMP Rule

1. Open the OCI VCN.
2. Select Security Lists or Network Security Groups.
3. Open the security configuration associated with bastion-server.
4. Inspect the ingress rules.
5. Add the ICMP rule if it does not already exist.

Setting	Value
Direction	Ingress
Source type	CIDR
Source CIDR	10.10.1.4/32
IP protocol	ICMP
ICMP type	8
ICMP code	0
Action	Allow

ICMP type 8 and code 0 represent an IPv4 Echo Request. This rule permits the Azure test VM to send ping requests to the OCI instance.

Verify Egress and Stateful Rules

Check the applicable egress rules and whether the security rules are stateful or stateless.

• Stateful rules generally permit response traffic for an allowed connection.
• Stateless rules may require explicit rules for return traffic.

Use the narrowest rules needed for the test.

19. Step 16 — Verify the Azure Linux Firewall

An Azure NSG can permit ICMP while the Linux operating system still blocks ping. The lab used a Linux VM and checked firewalld.

Connect to the Azure VM

Use the supported SSH or Azure management access method available for the VM.

Check the Firewall Service

Run:

sudo systemctl status firewalld

To check whether ICMP Echo Requests are blocked by firewalld, run:

sudo firewall-cmd --query-icmp-block=echo-request

If the output is yes, the firewall configuration blocks Echo Requests in the active zone. Review the active zone and its rules before changing anything.

If the output is no, that specific firewalld block is not configured. Other firewall rules can still affect ping.

Do not disable the entire firewall just to make ping work. Update only the necessary rule after confirming the active configuration.

Verify the OCI Instance Firewall

The OCI instance's operating-system firewall can also affect ICMP traffic. Check its firewall configuration using the appropriate commands for the installed operating system. Confirm that incoming Echo Requests and the required outbound traffic are permitted.

20. Step 17 — Test Private-IP Connectivity

After configuring the interconnect, routes, security rules, and firewalls, test connectivity in both directions.

Test 1 — OCI to Azure

Connect to the OCI instance bastion-server.

Run:

ping -c 4 10.10.1.4

Here, 10.10.1.4 is the recorded private IP of Azure-Test-VM.

Verify that the ping receives replies.

Test 2 — Azure to OCI

Connect to Azure-Test-VM.

Run:

ping -c 4 10.0.0.91

Here, 10.0.0.91 is the recorded private IP of bastion-server.

Verify that the ping receives replies.

Final Connectivity Result

Test	Source	Destination	Result
OCI to Azure	10.0.0.91	10.10.1.4	Successful
Azure to OCI	10.10.1.4	10.0.0.91	Successful

Lab result: Both private-IP ping tests were successful. Screenshots showing the successful tests are included with the lab documentation.

This confirmed private-IP reachability between the two workload VMs for the tested paths and firewall configuration. A successful ping verifies ICMP connectivity for these endpoints; it does not automatically verify every application port or every route in the environment.

21. Step 18 — Troubleshooting Checklist

If ping fails in a future test, check the following.

OCI Checks

• Verify that the instance is running.
• Verify its private IP.
• Verify the workload subnet and route table association.
• Verify the route to 10.10.1.0/24.
• Verify the DRG attachment and DRG routes.
• Verify the FastConnect virtual circuit state.
• Verify that IPv4 BGP is Up.
• Verify the OCI Security List or NSG.
• Check the operating-system firewall.

Azure Checks

• Verify that Azure-Test-VM is running.
• Verify its private IP.
• Verify the VNet and workload subnet.
• Verify the ExpressRoute circuit and provider status.
• Verify the ExpressRoute gateway provisioning state.
• Verify the gateway connection.
• Verify the private peering and BGP status.
• Check the learned and effective routes.
• Verify the NSG inbound rule.
• Check the Linux firewall.

Common Problems

Problem	What to Check
BGP is Down	BGP IP addresses, masks, ASNs, and provider configuration
Connection is not Succeeded	Gateway, circuit selection, and Azure connection status
OCI cannot reach Azure	OCI route table, DRG routes, and Azure inbound security rules
Azure cannot reach OCI	Azure return route, OCI ingress rules, and OCI firewall
Ping fails but BGP is Up	Workload routes, NSGs, Security Lists, and operating-system firewalls
CIDRs overlap	Recheck both cloud networks and all subnet ranges

22. Step 19 — Billing and Lab Cleanup

ExpressRoute circuits, virtual network gateways, FastConnect services, and compute resources can incur charges.

Before leaving the lab:

1. Check Azure Cost Management + Billing.
2. Check whether Azure credits are available and whether the services are eligible.
3. Review the ExpressRoute circuit and gateway pricing.
4. Stop the Azure VM and verify that its status becomes Stopped (deallocated) if you want to stop compute billing.
5. Remember that the VM's disks and some associated resources can continue to incur charges.
6. Review the OCI instance and any other billable resources.
7. If the lab is complete and you do not need to preserve the connectivity, plan the cleanup of the ExpressRoute circuit, gateway, connection, and FastConnect resources.
8. Follow the provider deprovisioning process before assuming the interconnect billing has ended.

Important: Stopping a VM does not stop ExpressRoute circuit or gateway billing. Azure credits should not be assumed to be available until the subscription's billing page confirms the credit balance.

Before deleting a resource, confirm that you no longer need it. Deleting networking resources will break the lab connectivity.

23. Key Learnings

During this practical lab, I learned how to:

• Create an Azure resource group and VNet.
• Configure separate workload and gateway subnets.
• Deploy a Linux VM for connectivity testing.
• Configure Azure NSG rules for ICMP.
• Create an Azure ExpressRoute circuit.
• Configure BGP peering and understand /30 transit networks.
• Deploy an Azure ExpressRoute virtual network gateway.
• Create the gateway connection to the ExpressRoute circuit.
• Configure OCI FastConnect and the DRG.
• Configure OCI route tables and security rules.
• Verify routing in both directions.
• Check Linux firewall settings.
• Test private-IP connectivity between OCI and Azure.

24. Conclusion

In this lab, I configured the OCI–Azure interconnect, established the required network routing and security rules, and verified private-IP connectivity between the OCI and Azure test VMs.

Both ping tests were successful.

This practical helped me understand how BGP peering, FastConnect, ExpressRoute, DRG routing, Azure gateway connections, CIDR planning, and ICMP security rules work together to provide private network connectivity between cloud environments.

STEPS

enter your personal information and credit card details to sign in.

creating Resource group

creating VCN

now creating subnet for Gateway

now creating virtual network gateway

now creating virtual machine

now creating express route

now everything is done from Azure side so now we have to go to OCI and create fast connect

copy the service key from Azure

now both side it is showing provisioned

now it is showing configuration match after 2 to 4 minutes

now go to Azure express route select your expressroute and click on setting -> connection and create connection

uncheck enable connection monitor

now open both the vm oci and azure and check ping

add route rule to DRG and security list(ICMP) in OCI

now pinging from OCI to Azure

now pinging from Azure to OCI

Note :-

BGP is a dynamic routing protocol that helps different networks share routes with each other. ASN is a number that identifies a network in BGP. In my OCI FastConnect and Azure ExpressRoute lab, BGP helps OCI and Azure learn each other's network routes automatically. However, route tables, gateway configuration, and security rules must still be configured and validated.

Interview Questions & Answers

Q1. What is OCI FastConnect?

OCI FastConnect provides private network connectivity to Oracle Cloud Infrastructure.

Q2. What is Azure ExpressRoute?

Azure ExpressRoute provides private network connectivity to Microsoft Azure.

Q3. What is BGP?

BGP is a dynamic routing protocol that helps different networks exchange routing information.

Q4. What is an ASN?

ASN stands for Autonomous System Number. It identifies an Autonomous System in BGP routing.

Q5. What is the role of DRG in OCI?

DRG (Dynamic Routing Gateway) connects OCI VCNs to external networks through supported network connectivity options.

Q6. Do we still need route tables when using BGP?

Yes. BGP exchanges routes, but route tables and security rules must still be configured correctly.

Q7. How did you verify connectivity?

I verified the network configuration and performed ping tests between the OCI and Azure test environments. The ping tests were successful in my lab.

Q8. What would you check if connectivity failed?

I would check BGP status, advertised and learned routes, route tables, security rules, and operating system firewall settings.