Troubleshoot OVHcloud Connect

Diagnose and resolve the most common issues encountered with OVHcloud Connect

Objective

This guide helps you diagnose and resolve the most common issues encountered with OVHcloud Connect. Each section describes a known issue, its possible causes, and the steps to fix it.

Before you begin

General considerations

Always check both sides — Most OVHcloud Connect issues involve configuration or physical elements on both your side and OVHcloud's side. Verify your router, cross-connect (or provider virtual circuit), and the OVHcloud Control Panel before opening a ticket.
Collect diagnostics first — Before making changes, gather interface status, BGP state, traceroute, and optical values. This information speeds up resolution whether you solve the issue yourself or need to contact support.
Check for scheduled maintenance — Some issues may be caused by planned work on OVHcloud infrastructure or at your provider. Always check the status page before deep-diving into troubleshooting.

Useful resources

Resource	Link
FAQ	Frequently Asked Questions
Glossary	Glossary of OVHcloud Connect terms
OVHcloud services status	status.ovhcloud.com
Prerequisites & Limitations	Prerequisites & Limitations
Monitoring guide	Monitor Your OVHcloud Connect
Incident follow-up	Declare and Follow Up Upon an Incident

Issue 1 — No light on the physical link (OVHcloud Connect Direct)

After ordering OVHcloud Connect Direct, the physical link shows no optical signal on one or both sides.

Possible causes and solutions

#	Possible cause	Solution
1	Cross-connect not yet installed	Contact your data centre operator and provide the LOA. See Ordering a Cross Connect with an LOA.
2	LOA misinterpreted by the data centre	Verify the LOA details with the PoP operator: cabinet, cage, patch panel, port, fibre termination. See How to read LOA information below.
3	Tx/Rx fibre inversion	The transmit and receive fibres may be swapped, causing light to arrive on the wrong port. Ask the data centre operator to check for a Tx/Rx inversion on the cross-connect.
4	SFP module issue	Ensure the SFP matches the ordered bandwidth: 1000Base-LX/LH for 1 Gbps, 10GBase-LR for 10 Gbps, 100GBase-LR4 for 100 Gbps. Replace the SFP if faulty. See Prerequisites & Limitations.
5	Port disabled or locked	Check the OVHcloud Control Panel — the port may be administratively locked. If the OUT optical value is DOWN, the port may also be in the process of being cancelled.
6	Faulty cross-connect cable	Ask the data centre operator to test the cable or provision a new one.

How to read LOA information

A typical LOA contains information formatted like this:

Equipment: 103 PA3:OG:00GMC3:OVH Patch Panel: PP:0103:1132697
Port: P16/FO31-32/BCK Fiber Termination: SC/PC

Interpretation:

Field	Value	Meaning
Cabinet	103	Position of the bay where the rack is located
Cage	PA3:OG:00GMC3:OVH	Rack reference
Patch Panel (Z-side)	PP:0103:1132697	Switch position on OVHcloud side
Port	16	Position on the switch
FibreOptic Port A	31	Fibre A identifier
FibreOptic Port B	32	Fibre B identifier
Side	BCK (Back)	Front or back of the equipment
Fibre Termination	SC/PC	Connector type

Checking optical values

In the OVHcloud Control Panel, navigate to Network → OVHcloud Connect → select your service, and check the IN/OUT optical values:

OUT is DOWN — The OVHcloud-side port is not emitting light. Possible reasons: port issue, service being cancelled, port locked, SFP failure.
IN is DOWN — OVHcloud is not receiving light from your side. Possible reasons: cross-connect not installed, your equipment not connected, your port disabled, Tx/Rx fibre inversion.

Diagnostic flowchart

Issue 2 — Ethernet link down (no peering) despite light being UP

Optical values show UP on both sides, but the Ethernet interface remains DOWN and no peering can be established.

Possible causes and solutions

#	Possible cause	Solution
1	SFP type mismatch	The SFP must match the ordered bandwidth. Use 1000Base-LX/LH for 1 Gbps, 10GBase-LR for 10 Gbps, 100GBase-LR4 for 100 Gbps.
2	Auto-negotiation enabled	Auto-negotiation is not supported on OVHcloud Connect. Disable it on your router (see commands below).
3	Speed mismatch	Your interface speed must match the ordered link speed. Configure it explicitly.
4	Faulty SFP or transceiver	Try replacing the SFP module on your side.

Disabling auto-negotiation

Cisco IOS:

interface GigabitEthernet0/0
 no negotiate auto

or:

interface GigabitEthernet0/0
 speed nonegotiate

Cisco NX-OS:

interface Ethernet1/1
 speed 1000
 no negotiate auto

Juniper JunOS:

set interfaces ge-0/0/0 ether-options no-auto-negotiation

Issue 3 — BGP session stuck in Active or Idle state

The physical link is up, but the BGP session does not reach the Established state.

Possible causes and solutions

#	Possible cause	Solution
1	Incorrect peer IP address	Verify that the peer IP configured on your router matches exactly the IP assigned by OVHcloud in the Control Panel. The PoP peering subnet is a /30: OVHcloud takes the first IP, you take the second. See Configure OCC L3 with BGP.
2	Incorrect ASN	Check that you are peering with OVHcloud ASN 35540 and that your own ASN is correctly configured (private ASN range 64512–65534 recommended). Avoid reserved ASNs: 65501 (EU PoP), 65502 (CA PoP), 65519 (Asia PoP).
3	VLAN ID mismatch	The VLAN tag on your interface must match the VLAN ID configured in the OVHcloud Control Panel PoP configuration. Verify with `show interfaces` or `show vlans`.
4	Firewall blocking TCP port 179	BGP uses TCP port 179. Ensure no firewall or ACL is blocking this port between the two peers.
5	Interface not configured with correct encapsulation	For L3 connections, the interface must use 802.1Q encapsulation with the correct VLAN ID. See configuration examples in the Configure OCC L3 with BGP.
6	PoP configuration not created in OVHcloud	Verify in the OVHcloud Control Panel that a PoP configuration has been created for your service. Without it, OVHcloud's router will not peer.
7	MD5 authentication mismatch	If MD5 is configured, the password must match on both sides. Check with your OVHcloud Connect service details.

Verification commands

Cisco IOS:

show ip bgp summary
show bgp ipv4 unicast neighbors 192.0.2.1
show interfaces GigabitEthernet0/0
show ip interface brief

Juniper JunOS:

show bgp summary
show bgp neighbor 192.0.2.1
show interfaces terse

Diagnostic flowchart

Issue 4 — BGP session established but no routes received

The BGP session shows Established, but no prefixes are being received from OVHcloud (or from your network).

Possible causes and solutions

#	Possible cause	Solution
1	Missing `network` statement or export policy	On your router, ensure you are advertising the correct prefixes using `network` commands (Cisco) or export policies (Juniper). See Configure OCC L3 with BGP.
2	Prefix filter blocking routes	Your import prefix-list may be too restrictive, filtering out OVHcloud routes. Check your prefix-lists and route policies.
3	vRack not associated	OVHcloud routes are only exchanged if the OVHcloud Connect service is associated with a vRack. Verify the association in the Control Panel. See Associate with vRack.
4	AZ subnets not configured	If no subnets are defined in the Availability Zone configuration, there will be no routes to exchange. See Set up your vRack network.
5	Maximum prefix limit reached	OVHcloud supports up to 100 prefixes per BGP session. If you exceed this limit, the session may stop accepting new routes. Aggregate your prefixes.
6	Route not in the routing table	The prefix you are trying to advertise must exist in your router's routing table (via a connected network, static route, or IGP).

Verification commands

Cisco IOS:

show ip bgp summary
show ip bgp neighbors 192.0.2.1 received-routes
show ip bgp neighbors 192.0.2.1 advertised-routes
show ip route bgp

Juniper JunOS:

show bgp summary
show route receive-protocol bgp 192.0.2.1
show route advertising-protocol bgp 192.0.2.1
show route protocol bgp

Issue 5 — BGP session keeps flapping (repeatedly going up and down)

The BGP session oscillates between Established and Active/Idle states, causing intermittent connectivity.

Possible causes and solutions

#	Possible cause	Solution
1	Unstable physical link	Check interface error counters (`show interfaces`) for CRC errors, input errors, or output drops. Inspect the SFP, cross-connect cable, and patch panel.
2	MTU mismatch	An MTU mismatch between your equipment and OVHcloud can cause large BGP update packets to be dropped. The default MTU is 1500 bytes. Confirm MTU settings on both sides.
3	BGP hold timer expiry	Default BGP hold time is 90 seconds. If keepalives are lost due to link instability, the session drops. Consider adjusting BGP timers, but fix the root cause first.
4	CPU or memory overload on your router	BGP processing may be delayed if the router is under high load. Check CPU and memory usage.
5	Aggressive prefix changes	Rapidly withdrawing and re-advertising routes can trigger flap dampening. Stabilise your routing announcements.

Verification commands

Cisco IOS:

show interfaces GigabitEthernet0/0
show ip bgp summary
show ip bgp flap-statistics
show log | include BGP

Juniper JunOS:

show interfaces ge-0/0/0 extensive
show bgp summary
show log messages | match BGP

Issue 6 — Traffic not flowing despite BGP session established and routes exchanged

BGP is up, routes appear in the routing table on both sides, but actual traffic (ping, application data) does not flow.

Possible causes and solutions

#	Possible cause	Solution
1	Firewall or ACL blocking traffic	Check firewall rules and access control lists on your router, your OVHcloud resources (security groups, iptables), and any intermediate devices.
2	VLAN tagging mismatch	The VLAN ID on your interface must match the VLAN configured in OVHcloud. A mismatch results in tagged traffic being silently dropped.
3	Incorrect subnet configuration	Verify that source and destination IPs belong to the correct subnets and that there are no overlapping ranges. See Set up your vRack network.
4	Asymmetric routing	If you have multiple paths (e.g. internet + OVHcloud Connect), return traffic may take a different path. Ensure symmetric routing using BGP attributes (Local Preference, AS-path prepending).
5	vRack resource not attached	The target OVHcloud resource (Bare Metal server, Public Cloud instance, Hosted Private Cloud) must be attached to the same vRack as OVHcloud Connect. Verify in the Control Panel.
6	MTU mismatch causing fragmentation	Large packets may be silently dropped if MTU differs between segments. Test with varying packet sizes: `ping -s 1472 -M do <destination>` (Linux) to check for fragmentation issues.

Verification commands

From your side:

ping 172.16.1.1
traceroute 172.16.1.1

From a Linux host in OVHcloud:

ping -c 10 10.0.0.1
traceroute 10.0.0.1
mtr -r -c 50 10.0.0.1

Issue 7 — Slow performance or high latency

The connection is working, but throughput is lower than expected or latency is higher than normal.

Possible causes and solutions

#	Possible cause	Solution
1	Bandwidth saturation	Check interface utilisation in the OVHcloud Control Panel and on your router. If you consistently exceed 80% of the provisioned bandwidth, plan an upgrade.
2	MTU mismatch causing fragmentation	Fragmented packets reduce effective throughput. Verify MTU end-to-end and run path MTU discovery: `ping -s 1472 -M do <destination>`.
3	Interface errors (CRC, FCS, drops)	Check `show interfaces` for error counters. Physical issues (dirty fibre, bad SFP, loose connector) cause retransmissions and degrade performance.
4	Sub-optimal routing	Traffic may be taking a longer path than expected. Check `traceroute` and BGP attributes (Local Preference, AS-path) to ensure optimal path selection.
5	Congestion at the provider	If using OVHcloud Connect Provider, check the provider's portal (Megaport, Equinix Fabric, Console Connect) for utilisation and alerts on the virtual circuit.
6	TCP window size misconfiguration	For high-bandwidth, high-latency links, ensure TCP window scaling is enabled on hosts to maximise throughput.

Verification commands

Cisco IOS:

show interfaces GigabitEthernet0/0 | include rate|error|drop|CRC
show ip route 172.16.1.0

From a Linux host:

iperf3 -c <destination> -t 30
mtr -r -c 100 <destination>

Issue 8 — Provider virtual circuit not connecting (OVHcloud Connect Provider)

You have ordered an OVHcloud Connect Provider service, but the connection through your provider (Megaport, Equinix Fabric, or Console Connect) is not coming up.

Possible causes and solutions

#	Possible cause	Solution
1	Incorrect pairing key / service key	Verify that the pairing key (or service key) entered in your provider's portal exactly matches the key from the OVHcloud Control Panel.
2	Provider virtual circuit not provisioned	Check the status of the VXC (Megaport), virtual connection (Equinix), or connection (Console Connect) in the provider's portal. It should show as "Active" or "Provisioned".
3	Provider does not have presence at the PoP	The provider must be available at the OVHcloud PoP you selected. Verify PoP availability in Providers and PoP Locations.
4	Bandwidth mismatch	The bandwidth ordered on the provider side must match or be compatible with the OVHcloud Connect service bandwidth.
5	Provider-side maintenance or outage	Check your provider's status page for ongoing incidents or planned maintenance.

Tip

Tip: If the provider portal shows the connection as "Active" but OVHcloud still shows it as "Pending", wait a few minutes for the provisioning to complete. If it persists beyond 30 minutes, contact OVHcloud support.

Issue 9 — Service ordered but not delivered / not configurable

Your OVHcloud Connect service appears in the Control Panel but cannot be configured.

Possible causes and solutions

#	Possible cause	Solution
1	Cross-connect not yet installed (Direct)	The service becomes configurable once OVHcloud detects light on the port. Order the cross-connect from your data centre operator using the LOA and ensure your equipment is connected.
2	60-day interconnection window (Direct)	After the order, you have 60 days to finalize the interconnection (order the cross-connect and interconnect your equipment). Beyond 60 days — even without detected light — the service is considered operational and billing starts.
3	Provider circuit not yet linked (Provider)	Ensure the provider virtual circuit is provisioned and linked to the OVHcloud service using the correct pairing key.
4	Provisioning in progress	New services may take a few minutes to become configurable after ordering. Wait and refresh the Control Panel.
5	Order issue	If the service remains in "Pending" state for an extended period, contact OVHcloud support with your order reference.

Issue 10 — Failover not working in Multi-AZ setup

You have two OVHcloud Connect links for redundancy, but traffic does not failover when one link goes down.

Possible causes and solutions

#	Possible cause	Solution
1	Both links in the same PoP	For true Multi-AZ resilience, the two links must terminate at different PoPs and different Availability Zones. See Multi-AZ.
2	BGP failover not configured	Configure BGP attributes to control path selection: use Local Preference to prefer the primary path and AS-path prepending on the backup. See Configure OCC L3 with BGP.
3	BFD not enabled	Without BFD, BGP failover relies on hold timers (default 90 seconds). Enable BFD (Bidirectional Forwarding Detection) to reduce failover time to under 1 second. Contact OVHcloud support to confirm BFD availability for your service.
4	vRack not shared between both services	Both OVHcloud Connect services must be associated with the same vRack for failover to work. Verify in the Control Panel. See Associate with vRack.
5	Prefix-list filtering backup routes	Ensure your import/export prefix filters allow the same prefixes on both links.

Verification commands

Cisco IOS:

show ip bgp
show ip bgp summary
show ip route bgp
show ip bgp neighbors 192.0.2.1
show ip bgp neighbors 198.51.100.1

Check that both BGP sessions are Established and that routes are received from both peers with different attributes (Local Preference, AS-path length).

Issue 11 — IP address conflict in PoP or DC configuration

BGP session may not establish, or traffic may be routed incorrectly due to IP address conflicts.

Possible causes and solutions

#	Possible cause	Solution
1	Using OVHcloud reserved IPs	In the PoP /30 subnet, the first IP is reserved for OVHcloud. In the DC /28 (minimum) subnet, the first three IPs are reserved for OVHcloud. Ensure you are using the correct IPs.
2	Overlapping subnets	Your on-premises subnets must not overlap with subnets used in the OVHcloud vRack. Plan your IP addressing carefully. See Set up your vRack network.
3	Duplicate ASN	Your BGP ASN must differ from OVHcloud's ASN (35540) and from the reserved ASNs (65501, 65502, 65519).

Issue 12 — Unsupported features or unexpected behaviour

Certain features may not work as expected due to current platform limitations.

Known limitations

Feature	Status	Notes
IPv6	Not supported	OVHcloud Connect currently supports IPv4 only.
QoS / CoS	Not supported	No quality of service or 802.1p class of service mechanisms.
802.1q VLAN tagging (L2 mode)	Supported	But L2 mode is available on OVHcloud Connect Direct only.
Multi-VRF	Not supported	Only a single routing instance per OVHcloud Connect service.
eBGP Multi-Hop	Not supported	BGP peering must be directly connected (single hop).
iBGP	Not supported	Only eBGP is supported.
Static routing at PoP	Not supported	All routing is done via BGP.
Spanning Tree (L2)	Not supported	L2 mode does not pass BPDUs.
Multicast / IGMP (L2)	Not supported	Only unicast traffic is supported in L2 mode.
FCoE (L2)	Not supported	Fibre Channel over Ethernet is not supported.
LACP (L2)	Supported	Can be used for link aggregation in L2 mode within a single PoP.

For the full list of prerequisites and limitations, see Prerequisites & Limitations.

Quick reference: diagnostic commands

Cisco IOS / IOS-XE

Purpose	Command
Interface status	`show interfaces GigabitEthernet0/0`
Interface brief	`show ip interface brief`
BGP session summary	`show ip bgp summary`
BGP neighbour details	`show bgp ipv4 unicast neighbors <peer-IP>`
Routes received from peer	`show ip bgp neighbors <peer-IP> received-routes`
Routes advertised to peer	`show ip bgp neighbors <peer-IP> advertised-routes`
BGP routing table	`show ip route bgp`
BGP flap statistics	`show ip bgp flap-statistics`
Logs	`show log \| include BGP`

Juniper JunOS

Purpose	Command
Interface status	`show interfaces ge-0/0/0 extensive`
Interface summary	`show interfaces terse`
BGP session summary	`show bgp summary`
BGP neighbour details	`show bgp neighbor <peer-IP>`
Routes received from peer	`show route receive-protocol bgp <peer-IP>`
Routes advertised to peer	`show route advertising-protocol bgp <peer-IP>`
BGP routing table	`show route protocol bgp`
Logs	`show log messages \| match BGP`

Linux host

Purpose	Command
Connectivity test	`ping -c 10 <destination>`
Path trace	`traceroute <destination>`
Combined ping + trace	`mtr -r -c 50 <destination>`
MTU test (no fragmentation)	`ping -s 1472 -M do <destination>`
Throughput test	`iperf3 -c <destination> -t 30`

When to contact support

If you have followed the troubleshooting steps above and the issue persists, open a support ticket:

From the , go to Support → Create a ticket.
Select Network → OVHcloud Connect.
Include:
- Your OVHcloud Connect service name/ID
- Timestamp of the issue (UTC)
- Symptoms observed
- Diagnostic outputs (BGP summary, interface status, traceroute, optical values)
- Steps already taken to troubleshoot
See Declare and Follow Up Upon an Incident for the full incident management process.

What's next?

Set up proactive monitoring to detect issues before they impact your users
Review Prerequisites & Limitations to avoid known pitfalls
Consult the FAQ for answers to common questions
Check SLAs for uptime guarantees and service credits

Go further

For training or technical assistance implementing our solutions, contact your sales representative or visit our Professional Services page to request a quote and have your project analyzed by our experts.

Join our community of users.

Was this page helpful?