Skip to content

BDIX Peering Direct Connect

Service ownership

Owner: network-platform (network-pm@clouddigit.ai) — Status: GA — Last audited: 2026-05-11

Dedicated, private interconnect to BDIX (Bangladesh Internet Exchange) — and through BDIX to ~600 ISPs, banks, government, and enterprises. Sub-millisecond domestic egress for the price of metro fibre.

What it is

A physical or virtualised port at one of Cloud Digit's BDIX-adjacent meet-me rooms, terminated in your VPC as a private interconnect. Skip the public internet entirely for traffic to/from BDIX peers.

Topology

graph LR
    subgraph "Your network / DC"
      You[Customer router]
    end
    subgraph "BDIX MMR"
      BDIX[BDIX switch]
      CD[Cloud Digit DCI]
    end
    subgraph "Cloud Digit"
      VPC[Your VPC]
    end
    You ---|cross-connect| BDIX
    BDIX ---|peer-link| CD
    CD ---|VRF/VLAN| VPC

Port options

Speed Form factor Best for
1 Gbps 1 GbE SFP SME, low-volume
10 Gbps 10 GbE SFP+ Standard FI, mid-volume
25 Gbps 25 GbE SFP28 Large FI, content provider
100 Gbps 100 GbE QSFP28 ISP, hyperscaler, content cache

VLAN model

A single physical port can carry multiple virtual interfaces — one per VPC, one per VRF/peer. Useful for multi-tenant or multi-environment splits (prod / non-prod / DMZ).

Why customers pick this over IPsec VPN

Concern VPN over Internet BDIX Peering Direct Connect
Latency Variable; routes outside BD Predictable, sub-ms within BD
Throughput Capped by gateway tier Full port speed
Predictability Internet-best-effort Carrier-grade fibre
Sovereignty Traffic may transit international links All-domestic by definition
Cost at scale Per-GB egress Flat per-port-month

Pricing

Flat per-port-month rate by speed; one-time install fee. Domestic egress over the port is unmetered. See Pricing.

Lead time

10–15 business days to install (cross-connect, port allocation, customer-side equipment readiness). Open a ticket with the requested speed and the colocation cabinet/DC.

Operate this service

Direct cross-connect to BDIX (Bangladesh Internet Exchange) for low-latency, low-cost peering with domestic networks.

Why BDIX peering

  • Sub-millisecond reach to most Bangladesh ISPs
  • Reduces transit costs (intra-BD traffic doesn't egress through international transit)
  • Required for serious content/SaaS providers serving BD users at scale

IAM

Role Can do
bdix.viewer Read BDIX connection state
bdix.operator Manage BGP sessions on existing connections
bdix.admin Create / decommission BDIX connections

bdix.admin is typically held by 1–2 senior network engineers.

Capacity tiers

Tier Committed Burst
bdix-1g 1 Gbps none
bdix-10g 10 Gbps none
bdix-100g 100 Gbps none

Bursting beyond committed is hard-shaped — buy the tier you need.

ASN and PI space

BDIX peering requires: - Your own ASN (or use Cloud Digit's AS for resale customers) - PI (provider-independent) IPv4/IPv6 space, or BYOIP via Cloud Digit - A signed BDIX membership agreement

Setup involves BDIX-side paperwork; budget 10–15 BWD.

Routing policy

Configure prefix announcements:

bash cd bdix bgp policy set --connection bdix-acme \ --announce 103.5.0.0/16 \ --filter peers-with-similar-policy

Default filter accepts routes from BDIX members; rejects defaults. Don't accept a default route from BDIX — that's a transit relationship, not peering.

Metrics

Metric Healthy Alert
bdix.bgp.state established other
bdix.bgp.routes_received matches expected sudden drop
bdix.bgp.routes_announced matches your policy sudden change
bdix.bytes_in / out varies sudden change
bdix.link.utilization_pct < 80% > 90%
bdix.link.errors_per_sec 0 > 0

Route-server vs bilateral

BDIX supports both: - Route-server peering — single BGP session to BDIX RS, get all member prefixes - Bilateral peering — direct BGP session to each member

Most members start with route-server, add bilateral for the few partners they need to control policy with.

Looking-glass and traceroute

BDIX provides a public looking glass; use it to verify your routes are visible to other members:

http://lg.bdix.net.bd/ → select your ASN → view advertised prefixes

If a prefix you announce isn't visible: check bdix.bgp.routes_announced and your prefix filter.

Capacity planning

  • 80% sustained utilization → plan the next upgrade
  • Major events (Eid, election, cricket finals) drive 2–3× normal traffic; pre-arrange burst capacity with BDIX
  • 100G upgrades typically need 10+ BWD lead time

Failure modes

Failure Impact
BGP session drops Traffic re-routes via transit (slower, more expensive)
Physical link down Same
Route-server prefix wipe (rare) Loss of indirect peering routes; bilateral routes survive

Always have redundant transit as fallback. BDIX is for performance + cost; transit is for survival.

BGP session not establishing

Cause Check
Wrong ASN configured cd bdix bgp show --connection <name>
MD5 password mismatch Coordinate with BDIX NOC
Cross-connect physical issue Cloud Digit NOC tickets BDIX
Route-server policy not accepted BDIX side has a member-policy filter

Routes received but no traffic

  • Are routes installed in your route table? cd network route-table show
  • Is forwarding enabled on the BDIX-facing route? bdix.link.utilization_pct should be > 0 if any traffic flows
  • Security groups still apply — BDIX peers reach your VPCs subject to SG rules

Sudden drop in received routes

WARN: bdix.bgp.routes_received dropped from 14523 to 8741

Likely causes: - A major member withdrew their routes (check BDIX status page) - Your filter became more restrictive - Route-server session flapped

Compare to the public looking glass to distinguish "your view changed" from "everyone's view changed."

Buy more capacity, or shed traffic:

  • Promote a CDN POP closer to the edge
  • Route specific destinations away from BDIX to transit (rare; usually you'd do the opposite)
  • Negotiate with the destination ASN for bilateral peering on a different path

Asymmetric routing

Cloud Digit → BDIX peer is fine, but return traffic comes back via transit (suboptimal latency):

  • Peer's prefix announcement to BDIX is missing your range
  • They have a stricter inbound filter
  • Talk to their NOC; this is a peering policy issue

Member disputes / policy

BDIX peering operates on community norms. Most "issues" with another member are policy disagreements (filter mismatch, capacity, etc.). Resolution: - Open with their NOC directly (peering coords on PeeringDB) - Escalate to BDIX secretariat if no response - Document everything; peering disputes can take weeks