Cross-Connect¶
Service ownership
Owner: dc-operations (colo-pm@clouddigit.ai) — Status: GA — Last audited: 2026-05-11
In-DC fibre interconnect — between your rack and another tenant, between your rack and a carrier, or between your rack and Cloud Digit cloud fabric.
Why this matters¶
Colocation isn't useful in isolation; the value comes from what your rack can talk to without going out to the public Internet. Cross-connects are how you link your rack into the broader DC ecosystem.
Common cross-connect targets¶
| Target | Use case |
|---|---|
| Cloud Digit cloud fabric | Hybrid cloud — colo + cloud |
| BDIX MMR | Direct BDIX peering — see BDIX Peering Direct Connect |
| On-site carriers (BTCL, Summit, Fiber@Home, Robi, GP, etc.) | Internet transit, MPLS, dark fibre |
| Other tenant's cage | B2B private fibre (e.g., bank ↔ payment gateway) |
| Customer's other racks | Inter-rack within the same DC |
Speeds¶
| Handoff | Speeds available |
|---|---|
| Single-mode fibre | 1G, 10G, 25G, 100G |
| Multi-mode fibre | 1G, 10G |
| Copper | 1G |
Pricing¶
- Install — one-time per cross-connect
- Monthly — flat per cross-connect, by speed (within the same DC)
See Pricing.
Lead time¶
3–10 business days, depending on target — same-cage cross-connects are fastest, customer-cross-connects to other tenants take longer (need their consent).
Related¶
Operate this service¶
Physical fiber connections between your rack/cage and another CD customer's footprint, or to a partner network (BDIX, telco, vendor).
When to use¶
- Connecting two of your own deployments (rack to cage; primary to DR site within same DC)
- Connecting to a partner customer (e.g., bank's gear connected to a payment processor in the same DC)
- Connecting to BDIX (see BDIX Peering)
- Connecting to a telco PoP for direct WAN
IAM¶
| Role | Can do |
|---|---|
xconnect.viewer | View existing cross-connects |
xconnect.requester | Request new cross-connects |
xconnect.admin | Approve, terminate cross-connects |
Provisioning¶
bash cd colo xconnect request \ --from rack-acme-bd-dha-1-r042 \ --to bdix-meet-me-room \ --media single-mode-fiber \ --speed 10gbps \ --priority normal
Lead time: - Same-DC, same-row: 3-5 BWD - Same-DC, different floor: 5-10 BWD - Partner network (BDIX/telco): 10-15 BWD (paperwork)
Both-customer authorization¶
A cross-connect between two customers requires authorization from both:
- Customer A files request
- CD generates pending request for Customer B
- Customer B approves (with their own
xconnect.admin) - CD provisions
Either side can terminate; both sides notified.
Speed and media¶
| Speed | Media |
|---|---|
| 1 Gbps | Multi-mode fiber (LC duplex) |
| 10 Gbps | Single-mode fiber (LC duplex) |
| 25 Gbps | Single-mode fiber (LC duplex) |
| 100 Gbps | Single-mode fiber (LC duplex) or MTP/MPO |
You provide the SFP/QSFP at your end; CD provides at the patch panel.
Related¶
Metrics¶
| Metric | Healthy | Alert |
|---|---|---|
xconnect.link.state | up | down |
xconnect.link.utilization_pct | varies | sustained > 90% |
xconnect.link.errors_per_sec | 0 | > 0 |
xconnect.link.crc_errors_per_sec | 0 | > 0 (cable/optic degrading) |
Capacity planning¶
Cross-connects are physical — adding capacity = adding cross-connects:
- 80% sustained utilization → order another cross-connect
- LACP-bundle multiple cross-connects for higher aggregate
- Major events (Eid, election) → temporary boost via additional cross-connects
Maintenance¶
CD-side maintenance on cross-connects (rare; usually meet-me-room work): - Pre-announced 14 days in advance - Coordinated across all customers in the affected MMR - LACP redundancy keeps traffic flowing
Customer-side: bring your own redundancy. A single cross-connect with no LACP peer is a single point of failure.
BGP peering (BDIX, telcos)¶
For cross-connects carrying BGP: - Static or dynamic BGP — both supported - MD5 authentication recommended - Filter inbound to accept only routes you expect
See BDIX Peering — Operation for BDIX specifics.
Decommissioning¶
bash cd colo xconnect terminate --xconnect-id <id> --notice 30d
30-day notice for the other side. After termination, the physical fiber is reclaimed by CD.
Related¶
Cross-connect down¶
xconnect.link.state = down:
- Check your side: is your switch port up? Cable plugged?
- Check optic: light levels on your SFP?
- CD smart-hands can verify patch panel side
- If still down: cable fault — CD replaces, lead time hours
Intermittent errors¶
xconnect.link.errors_per_sec > 0 or CRC errors: - Optic going bad — replace - Cable degrading (rare for short MMR runs; more common for inter-floor) - Speed/duplex mismatch — verify both ends configured the same - Bent fiber — visual inspection
High utilization¶
xconnect.link.utilization_pct > 90% sustained: - Real traffic growth — order more cross-connects (lead time) - Misbehaving traffic (DDoS, traffic loop) — fix at source - Inefficient routing (traffic going across DC when it could stay in rack) — fix at L3
BGP session issues on cross-connect¶
See BDIX troubleshooting for BGP-specific. Common cross-connect-side issues: - Wrong VLAN tag on the trunked cross-connect - L2 reachability fine but L3 (BGP) authentication failed - ARP cache stale
Cross-connect to another customer not working¶
Both sides authorized, CD provisioned, but traffic doesn't flow: - Both sides need to configure their end: VLAN tags, IP, ARP - Authorization doesn't auto-configure — it just permits the physical link - Coordinate with the other customer's network team
Lead-time expectations not met¶
CD missed the provisioning ETA: - Same-DC delays usually mean material shortage or smart-hands queue - Partner-network delays usually paperwork (BDIX, telco)
Escalate via Customer Engineer; SLA credit applies for missed dates > 5 BWD.
Decommissioning conflict¶
Other side claims they still need the cross-connect: - Confirm via written notice - 30-day notice gives both sides time to migrate - After 30 days, CD physically removes — they can re-order if needed