Oracle FastConnect Troubleshooting
Oracle FastConnect issues can originate on the Tata Communications side, on the Oracle side, or sit ambiguously between the two. Use the triage below to place the symptom, then follow the diagnostic steps. For ambiguous issues, start with Tata Communications support.
Triage
|
Symptom points to |
Examples |
|
Tata Communications side – raise a TCx service request |
Circuit not provisioning after the OCI/VC-ID is shared; BGP transit subnet unreachable |
|
Oracle side – handle in your OCI console |
FastConnect creation errors; VCN/DRG attachment issues; route-table problems |
|
Ambiguous – start with us |
BGP up but no routes received; prefix-limit drops; intermittent loss; asymmetric routing |
Tata Communications-side issues
Circuit not provisioning
The FastConnect circuit does not move to a provisioned state after you shared the OCI/VC-ID.
Diagnostic steps: Confirm you shared the correct OCI/VC-ID with Tata Communications via the TCx Portal (without it, the partner side cannot provision); confirm the chosen serviceprovider in OCI matches the path you ordered (Tata Communications Layer 3/Layer 2 for the direct path, or the partner exchange); confirm the peering location is supported.
Resolution: Raise a TCx service request with the OCI/VC-ID and order details.
BGP transit subnet unreachable
You cannot ping the Oracle peer IP on the /30 transit subnet from your CPE.
Diagnostic steps: On the default Layer 3 delivery, first confirm the session is up and the IP is pinging between Oracle and the Tata Communications PE WAN IP – the Layer 3 BGP runs between Oracle and Tata Communications, not from your CPE. If it is down, raise a TCx service request. The CPE-side checks below apply where you run the session (Layer 2).
Confirm the VLAN/C-tag matches Tata Communications’ allocation; confirm the IP allocation matches (Private peering uses a Tata Communications-allocated /30 private; Public peering uses an Oracle-allocated /30 public); confirm no customer-side ACL is blocking the subnet.
Resolution: If VLAN, IP and ACL are correct, raise a TCx service request.
BGP session not establishing
Session in Idle or Active, never Established, but ping works.
Diagnostic steps: On the default Layer 3 delivery, first confirm the session is up and the IP is pinging between Oracle and the Tata Communications PE WAN IP – the Layer 3 BGP runs between Oracle and Tata Communications, not from your CPE. If it is down, raise a TCx service request. The CPE-side checks below apply where you run the session (Layer 2).
Verify the remote ASN is 31898 and your local ASN matches what you set in OCI; verify MD5 (if used, identical on both sides); for Public peering, confirm you are advertising public IPs owned by your organisation with a public ASN.
Resolution: If ASN and MD5 are correct, raise a TCx service request with your sanitised BGP configuration excerpt.
Prefix-limit drops
The session establishes then drops repeatedly.
Diagnostic steps: Check whether your advertised prefix count exceeds Oracle’s limit – 2,000 IPv4 / 500 IPv6 on Private virtual circuits, 200 on Public. Oracle drops the session when the limit is exceeded and re-establishes it when advertisements fall back under the limit.
Resolution: tighten your outbound prefix filter to stay within the limit.
Intermittent packet loss
Connection up but periodic loss.
Diagnostic steps: Check whether utilisation is at or near the circuit’s bandwidth (Tata Communications can confirm); for BFD-enabled sessions, check for flapping and confirm matching 300 ms × 3 timers; check interface errors on your CPE.
Resolution: If utilisation is consistently high, plan a bandwidth upgrade in the Oracle portal, otherwise raise a TCx service request.
Oracle-side issues
|
Symptom |
Where to look |
|
OCI console cannot create the FastConnect circuit |
FastConnect prerequisites in your OCI tenancy |
|
Dynamic Routing Gateway not attaching |
DRG / VCN attachment state |
|
Routes received but traffic doesn’t reach OCI resources |
VCN route tables, security lists, network security groups |
|
Public peering: prefixes not accepted |
Confirm advertised prefixes are public and owned by your organisation |
Ambiguous issues – start with Tata Communications support
For symptoms that could be on either side – BGP established but no routes received, one-way (asymmetric) traffic, MTU-related drops, or intermittent reachability – Raise a TCx service request with:
-
The OCI/VC-ID and Oracle region
-
Timestamps when the issue began
-
Your CPE BGP session state (sanitised of MD5 keys)
-
A description of the affected traffic flow.
Need more help?
If this guide doesn’t resolve the issue or you’re unsure which side it’s on, contact Tata Communications support – we will engage cloud service provider where the diagnosis points to the Oracle side.