Each Virtual Interface on an IZO™+ Multi Cloud Connect Hosted Connection runs a BGP session between the Tata Communications Virtual Cloud Connection and AWS. On the AWS Virtual Interface you set the BGP ASN to 4755, your sites reach AWS across the Tata Communications MPLS backbone. This page covers the parameters you set, ASN guidance, prefix filtering, path control for redundant deployments, and faster failover with BFD.
The role of BGP
Three VIF types are supported, each with the same underlying BGP mechanics; the differences are in what AWS advertises and what filters apply:
-
Private VIF – peer with AWS to reach a VPC.
-
Public VIF – peer with AWS to reach public AWS services over the dedicated connection.
-
Transit VIF – peer with a Transit Gateway to reach multiple VPCs across regions over one connection.
BGP parameters to configure
Each session needs the following set consistently on both sides. AWS provides the AWS-side values in the VIF details.
|
Parameter |
Description |
Where it comes from |
|
BGP ASN (on the VIF) |
Tata Communications ASN |
4755 - from Get Network Config |
|
AWS ASN |
AWS’s ASN |
AWS, in the VIF details (region-dependent) |
|
Your router peer IP |
Your side of the /30 |
From Get Network Config (Primary Peer IP) |
|
AWS router peer IP |
AWS side of the /30 |
From Get Network Config (Primary Cloud IP) |
|
MD5 key |
Shared BGP authentication secret |
You choose, identical on both sides |
|
VLAN ID |
802.1Q tag on the Hosted Connection |
Tata Communications, at provisioning |
ASN guidance
The ASN matters because BGP loop prevention relies on it appearing in the AS-PATH.
-
On every AWS Virtual Interface, set the BGP ASN to 4755 - the Tata Communications ASN shown in Get Network Config. AWS peers with the Tata Communications Cloud VC, not with your CPE directly.
-
Your own AS number is captured separately at ordering (the "AS Number" field on the Virtual Cloud Connection) and is used on the Tata Communications side.
-
AWS uses a region-dependent ASN on its side; it is shown in the VIF details.
MD5 authentication
Always configure MD5 on BGP sessions over IZO™+ Multi Cloud Connect – it protects against rogue session establishment. Use a strong shared secret (at least 16 characters, mixed case and digits), stored in your secrets vault. Both ends must match; an MD5 mismatch is a common reason sessions fail to establish.
Prefix filtering
Filter what you advertise and what you accept.
-
Outbound (to AWS): advertise only the on-premises prefixes that need to reach AWS. AWS accepts a maximum of 100 prefixes on each session, so summarise where you have more.
-
Inbound (from AWS): accept only the prefixes you expect from your VPC CIDR. A typical Private-VIF inbound filter accepts only the VPC CIDR (for example 10.20.0.0/16) and rejects the rest.
Redundant deployments
Where two Hosted Connections are provisioned, AWS presents them as active/active. Tata Communications tunes path preference on its own side so that one connection acts as primary and the other as secondary, and will align this with your on-premises routing policy. Agree the intended behaviour – active/backup or load-shared – with your account team when the second connection is ordered.
Faster failover with BFD
BGP’s default failure detection is slow (tens of seconds on hold-timer expiry). BFD sends rapid keepalives and tears the session down within milliseconds when they stop, triggering reconvergence. AWS supports BFD on Direct Connect at a minimum interval of 300 ms × 3, giving detection in about 900 ms. Configure matching timers on both sides.
Verification
After configuring, confirm:
-
BGP session state Established
-
Prefixes received match your VPC CIDR (Private VIFs)
-
Prefixes advertised match your outbound filter
-
BFD state Up (if enabled).
If a session doesn’t establish, check in order:
-
IP reachability on the BGP transit subnet (ping the AWS router IP)
-
The VLAN tag matches Tata Communications’ allocation
-
The MD5 key matches
-
The ASN values match what AWS shows in the VIF details.
For deeper triage, see AWS Troubleshooting.