Troubleshoot routing and BGP
This guide helps you diagnose and resolve common routing and BGP issues with Magic Transit. These issues can affect traffic delivery, cause unexpected latency, or result in connectivity loss.
If you are experiencing routing or BGP issues, check these items first:
- BGP session state: Verify session is Established, not stuck in Connect or Active.
- Firewall rules: Ensure TCP port
179is permitted bidirectionally between your router and Cloudflare. - Prefix advertisement status: Confirm prefixes show Advertised in the dashboard, not Withdrawn or Approved.
- Route propagation timing: Allow two to five minutes for changes to propagate globally. Cloudflare propagates changes within minutes, but has no control over how quickly external ISPs refresh their BGP tables.
- Tunnel or CNI health: Check that underlying connectivity is healthy. Degraded tunnels affect route priority.
- Static route conflicts: Static routes take precedence over BGP routes at equal priority.
When you advertise or withdraw a BYOIP prefix, changes propagate across Cloudflare's network within minutes.
| Action | Cloudflare propagation | Global Internet propagation |
|---|---|---|
| Prefix advertisement | 1-2 minutes | 2-5 minutes typical |
| Prefix withdrawal | 1-2 minutes | 2-15 minutes (BGP path hunting) |
When a route is withdrawn, Internet networks perform BGP path hunting. They search for alternative paths before converging on the new routing state. This behavior is amplified by:
- Cloudflare's global anycast network and extensive peering relationships
- The Minimum Route Advertisement Interval (MRAI), typically 30 seconds per iteration
- Multiple Tier-1 networks needing to converge independently
During path hunting, traffic may be routed suboptimally or dropped entirely.
Refer to Safely withdraw a BYOIP prefix for the recommended procedure.
This section covers BGP peering sessions (beta) between your network and Cloudflare, established over CNI or tunnels. These sessions are separate from how Cloudflare advertises your prefixes to the Internet, which is covered in Route propagation timing.
- BGP session never reaches Established state
- No routes being advertised or received
- Router logs show repeated connection attempts
| State | Meaning | Action |
|---|---|---|
| Established | Session up, exchanging routes | Normal operation |
| Active | Attempting to initiate connection | Check firewall rules, verify neighbor IP |
| Connect | TCP connection in progress | Check port 179 access, verify peering IP |
| Idle | Session down, no connection attempts | Check configuration, verify BGP is enabled |
- Verify your firewall permits TCP port
179bidirectionally between your router and the Cloudflare peering address. - Confirm the neighbor IP matches the Cloudflare-provided peering address exactly.
- Verify your ASN configuration matches the dashboard settings. Only eBGP is supported, so your ASN must differ from the Cloudflare account ASN.
- If using MD5 authentication, verify the password matches on both sides.
- Dashboard shows prefix as Advertised
- External hosts cannot reach IPs in the prefix
- Traffic is dropped
- Route propagation still in progress
- Missing return path routing on your network
- ROA/RPKI validation issues with upstream ISPs
- Wait for propagation: Allow up to five minutes for full global propagation. Changes propagate across Cloudflare quickly but external networks update at varying speeds.
- Verify return path routing: Ensure your network has routes to send return traffic back through Cloudflare for egress configurations. For ingress-only or direct server return configurations, route return traffic through your tunnels.
- Check external visibility: Use BGP looking glass tools such as bgp.he.net or RIPE RIS to confirm your prefix is visible from external networks.
- Verify RPKI configuration: If you use Resource Public Key Infrastructure (RPKI), confirm your Route Origin Authorization (ROA) records match your prefix and the ASN configuration in Cloudflare.
- Prefix withdrawn through API or dashboard
- External traffic continues arriving at Cloudflare but is dropped
- Connectivity loss persists for several minutes after withdrawal
This is BGP path hunting behavior. When Cloudflare withdraws your prefix, Internet networks search for alternative paths. Convergence typically takes two to five minutes but can extend beyond 11 minutes. During this period, traffic may:
- Route to Cloudflare through cached paths at ISPs
- Loop between Tier-1 providers that have not yet converged
- Be dropped before reaching your network
Follow the safe prefix withdrawal procedure:
- Before withdrawal: Advertise the same prefix (identical prefix length) from your alternate provider. This gives BGP an immediate alternative path.
- Optional - deprioritize Cloudflare: Add AS prepends to Cloudflare's route to make it less preferred, allowing traffic to shift gradually.
- Withdraw from Cloudflare: Request prefix withdrawal through the API or dashboard.
- Wait for convergence: Allow at least 15 minutes before considering the migration complete.
Using identical prefix lengths from both Cloudflare and your ISP prevents path hunting. Networks immediately have an alternative route available.
Refer to Safely withdraw a BYOIP prefix for detailed instructions.
- Traffic from specific regions routed through distant data centers
- Higher than expected latency for regional users
- Traffic not using the closest tunnel or CNI
- Tunnel health degradation causing route deprioritization
- Regional route scoping misconfiguration
- BGP route priorities not set as expected
- Static routes overriding BGP routes
-
Check tunnel health: Degraded tunnels have 500,000 added to their route priority. Down tunnels have 1,000,000 added. Traffic shifts to healthier paths, which may be in different regions. Refer to Troubleshoot tunnel health for diagnostic steps.
-
Review route priorities: Lower priority values indicate higher preference. Verify your routes have the expected priority configuration.
- Default BGP route priority:
100 - Static routes at priority
100take precedence over BGP routes at100
- Default BGP route priority:
-
Check regional scoping: If you use region-scoped routes, ensure all regions have route coverage. Traffic arriving at a region without a matching route is dropped.
-
Use Network Analytics: Review traffic patterns to identify where traffic is landing and which paths it follows. Refer to Network Analytics for usage instructions.
- CNI shows down in dashboard
- BGP session over CNI drops
- Traffic fails over to tunnels or alternate CNIs
CNI issues can occur at multiple layers:
| Issue type | Impact | What to check |
|---|---|---|
| Physical link down | All traffic over that CNI affected | Light levels, cross-connect status |
| BGP session down | Dynamic routes withdrawn | BGP neighbor state on your router |
| Prefixes withdrawn | Specific routes unavailable | BGP advertised and received routes |
A healthy physical link can still have BGP issues. A healthy BGP session can exist while specific prefixes are withdrawn.
Check physical layer (your side):
- Verify the interface is administratively up on your router.
- Check optical light levels (Tx/Rx dBm). Abnormal readings indicate fiber or transceiver issues.
- If light levels are low or absent on your receive side, contact your data center to verify cross-connect status.
Check BGP session:
- Verify BGP neighbor state on your router shows Established.
- Check for MD5 authentication mismatches if authentication is configured.
- Review BGP logs for error messages indicating why the session may have dropped.
Check for maintenance:
- Review Cloudflare Status ↗ for scheduled maintenance affecting your CNI location.
- Some maintenance events may temporarily affect CNI connectivity even when marked as non-disruptive.
Refer to Network Interconnect for CNI configuration and setup information.
- BGP routes not being used despite being learned
- Traffic not following expected BGP path
- Route changes not taking effect as expected
Cloudflare prefers static routes when static and BGP routes share the same prefix and priority. This ensures manually configured routes take precedence unless explicitly deprioritized.
Adjust route priorities based on your preference:
- To prefer BGP routes: Set static route priority to a higher number (for example,
150or200). Higher numbers indicate lower preference. - To prefer static routes: Keep static route priority at or below
100. BGP routes default to priority100.
| Route type | Prefix | Priority | Selected |
|---|---|---|---|
| Static | 10.0.0.0/24 | 100 | Yes (static wins ties) |
| BGP | 10.0.0.0/24 | 100 | No |
To make the BGP route preferred in this example, change the static route priority to 150 or higher, or remove the static route entirely.
Refer to Route prioritization for detailed information on how priorities work.
Understanding the relationship between these components helps diagnose routing issues:
| Component | What it monitors | Impact when unhealthy |
|---|---|---|
| CNI health | Physical or virtual interconnect link status | BGP session may drop. All traffic over that CNI is affected. |
| Tunnel health | Logical GRE or IPsec tunnel through health check probes | Route priority penalized. Traffic steers to healthier tunnels. |
| BGP session | Control plane connectivity for dynamic routing | Dynamic routes withdrawn. Static routes remain unaffected. |
A healthy CNI can have an unhealthy tunnel if health check probes are blocked or misconfigured. BGP routes can be withdrawn even when the underlying physical link is operational.
If you have worked through this guide and still experience routing issues, gather the following information before contacting Cloudflare support.
- Account ID and affected prefix(es), tunnel name(s), or CNI identifier(s)
- Timestamps (in UTC) when the issue occurred
- BGP configuration details:
- Your ASN and Cloudflare peering ASN
- Neighbor IP addresses
- Sanitized router configuration (remove passwords and keys)
- Current state information:
- BGP session state from your router
- Dashboard screenshots showing prefix, route, or tunnel status
- External BGP visibility: Results from looking glass tools showing your prefix
- Router logs: BGP neighbor logs covering the incident timeframe
- Traceroute results: From affected source networks to your prefix
- For CNI issues: Optical light level readings from your equipment
Collect output from these commands (syntax varies by vendor):
# Show BGP neighbor statusshow bgp neighbors
# Show BGP summaryshow bgp ipv4 unicast summary
# Show specific prefix in BGP tableshow bgp ipv4 unicast <YOUR_PREFIX>
# Show interface status (for CNI)show interface <YOUR_INTERFACE_NAME>
# Show received and advertised routesshow bgp ipv4 unicast neighbors <YOUR_NEIGHBOR_IP> routesshow bgp ipv4 unicast neighbors <YOUR_NEIGHBOR_IP> advertised-routes- Traffic steering: Route prioritization, BGP communities, and ECMP behavior
- Advertise prefixes: BGP control methods and safe withdrawal procedures
- Configure routes: Static route configuration
- Network Interconnect: CNI setup and BGP peering
- Troubleshoot tunnel health: Tunnel-specific diagnostic steps
- Network Analytics: Traffic analysis and monitoring
- Cloudflare Status ↗: Maintenance and incident notifications