<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1705902170274878&amp;ev=PageView&amp;noscript=1">
Skip to content
Talk to Us
  • There are no suggestions because the search field is empty.

BGP Troubleshooting

Most BGP problems on IZO™+ Multi Cloud Connect come down to three questions: is the session establishing, are the right prefixes being exchanged, and is traffic taking the intended path. This playbook works through each at parameter level. It does not include device configuration syntax; correct the parameters on your side and the cloud side, and raise an incident if a correctly configured session still fails. 

The peering facts to check against

Parameter

Value

Tata Communications ASN

4755 (fixed)

Azure ASN (private and Microsoft peering)

12076

Oracle ASN

31898

Resilient-path BGP local preference

400 / 300 / 200 / 100 (primary to quaternary)

AS-PATH prepend (secondary / tertiary / quaternary)

4755 2 / 4755 3 / 4755 4

BFD timer (standard)

300 ms x 3

Session will not establish

Work top down: 

Check

What to confirm

Physical and logical path

The underlying connection is up and the cloud-side hosted connection or virtual circuit has been accepted. If the link itself is down, resolve that first (see Connection Troubleshooting).

Peer addressing

The BGP peer addresses on both ends match the addressing set for the service.

ASN

You are peering with the Tata Communications ASN 4755, and your own ASN is the one supplied at ordering (for Azure and Oracle the cloud ASN is fixed, as above).

Authentication

Any BGP authentication (for example an MD5 key) matches on both ends.

BFD

If BFD is enabled, timers are compatible; the standard is 300 ms x 3.

Prefixes are not exchanged

If the session is up but routes are missing:

  • Confirm the prefixes you intend to advertise are actually being advertised from your side and are within any agreed limit.

  • Confirm the prefixes you expect from the cloud are being advertised on the cloud side (for example the virtual network or VPC ranges), and that the peering type matches what you need: public peering to reach public-IP resources, private peering for private-subnet resources, and a transit or combined option where both are needed over one link.

  • Confirm no route filter on either side is dropping the prefixes.

Traffic takes the wrong path

On resilient designs the cloud may treat both circuits as active/active, while Tata Communications tunes BGP to an active/backup behaviour using local preference and AS-PATH prepend (values above). If traffic favours the wrong circuit:

  • Confirm which circuit is primary in the design, and that the local-preference and prepend pattern matches the intended primary to quaternary order.

  • Remember that return traffic follows the cloud side’s own best-path decision; asymmetry is expected unless both directions are tuned.

What’s on the cloud side The BGP peering at the far end is configured in the cloud provider’s console. This page covers the parameters and behaviour on the Tata Communications side; for the cloud-side peering, keys and route configuration, see the relevant per-cloud section. 

Related pages