IBM Cloud Direct Link Troubleshooting

IBM Cloud Direct Link issues can originate on the Tata Communications side, on the IBM Cloud 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 TC^x service request	Gateway not appearing after the IBM Account ID is shared; BGP transit subnet unreachable
IBM Cloud side – handle in your console	Gateway pending acceptance; VPC route or resource issues
Ambiguous – start with us	BGP up but no routes received; prefix-limit drops; intermittent loss; asymmetric routing

Tata Communications-side issues

Gateway not created or not appearing

You shared your IBM Account ID but no gateway has appeared to accept.

Diagnostic steps:

Confirm you shared the correct IBM Account ID with Tata Communications via the TC^x Portal
Confirm the bandwidth and peering location are supported
Check the TC^x Portal for the order status.

Note that Tata Communications creates the gateway and then shares the Gateway Name and Service ID for you to accept – if you have not received these, raise a TC^x service request.

BGP transit subnet unreachable

You cannot ping the IBM peer IP on the /30 transit subnet from your CPE.

Diagnostic steps: On the default Layer 3 delivery the BGP runs between Tata Communications and IBM, not from your CPE; if peering does not come up, confirm the gateway was accepted in IBM Cloud, then raise a TC^x service request. The CPE-side checks below apply where you run the session (Layer 2).

Confirm the VLAN matches Tata Communications’ allocation; confirm the IP allocation matches (Private peering uses a /30 private allocated by Tata Communications or IBM); confirm no customer-side ACL is blocking the subnet.

Resolution: If VLAN, IP and ACL are correct, raise a TC^x service request.

BGP session not establishing

Session in Idle or Active, never Established, but ping works.

Verify the remote ASN is 13884 and your local ASN matches what you provided; verify MD5 (if used, identical on both sides)

Resolution: If ASN and MD5 are correct, raise a TC^x 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 IBM’s limit – 200 prefixes per peer (Private and Public). IBM brings the session down 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); check for BFD flapping and confirm matching timers; check interface errors on your CPE.

Resolution: If utilisation is consistently high, request a bandwidth change; otherwise raise a TC^x service request.

IBM Cloud-side issues

Symptom	Where to look
Gateway stuck pending	The gateway acceptance step in your IBM Cloud console
Routes received but traffic doesn’t reach resources	VPC route tables, security groups, access control lists

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 TC^x service request with:

The Gateway Name / Service ID and IBM 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 IBM where the diagnosis points to the IBM Cloud side.