Atman cross-connect BGP session down: diagnosing flapping and restoring peering
Restore a BGP session over an Atman cross-connect when peering drops due to physical layer faults, MTU issues, or hold timer expiry.
For EU sovereign infrastructure strategy and datacenter selection, see our EU sovereign cloud solutions page. For a real migration project involving EU datacenter placement, see our case study on moving infrastructure to the EU.
Symptoms
BGP peering session is Idle, Active, or oscillating between Established and Idle:
# Check BGP session state (BIRD example)
birdc show protocols all atman_peer
# Name Proto Table State Since Info
# atman_peer BGP --- start 2026-07-07 Active Socket: Connection refused
# Or with FRRouting (vtysh)
vtysh -c "show bgp summary"
# Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
# 185.1.x.x 4 8364 0 0 0 0 0 never Idle
# Check interface status
ip link show eth1
# eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
# Check for rapid state changes (flapping)
journalctl -u bird --since "1 hour ago" | grep -c "atman_peer.*State change"
# Expected if flapping: >5 state changes per hour
If the interface shows NO-CARRIER, the issue is physical/layer-1. If the interface is UP but BGP is Active or Idle, the issue is layer-3 (configuration, MTU, or remote side).
Cause
BGP session failures over Atman cross-connects typically have one of these root causes:
- Physical layer fault. The fiber patch between your rack and the peering partner’s rack has been damaged, unplugged, or the SFP module has failed. Atman’s NOC can verify light levels on their patch panel.
- MTU mismatch. Atman cross-connects support jumbo frames by default (9000 bytes), but if one side is configured for 1500 and the other for 9000, BGP OPEN messages (which fit in 1500) establish briefly, then larger UPDATE messages get silently dropped, causing hold timer expiry.
- Hold timer expiry from packet loss. If the cross-connect passes some traffic but drops packets intermittently (dirty fiber, CRC errors), keepalives are lost and the session drops after the hold timer (default 90s).
- Remote side reconfiguration. The peering partner changed their BGP config (wrong ASN, changed password, removed your prefix from their policy).
- VLAN tagging mismatch. If the cross-connect requires a specific VLAN tag (some Atman cross-connects are tagged, especially multi-tenant ones), a mismatch will prevent any L2 connectivity.
Fix
Step 1: Verify physical layer (L1)
# Check interface carrier status
ip link show eth1
# If state DOWN or NO-CARRIER: physical issue
# Check for CRC errors or drops (indicates dirty fiber)
ethtool -S eth1 | grep -iE "crc|error|drop|frame"
# rx_crc_errors: 0 (should be zero)
# rx_frame_errors: 0
# Check SFP module light levels (if supported)
ethtool -m eth1
# Laser output power: -2.5 dBm (normal: -1 to -5 dBm)
# Receiver signal average optical power: -8.2 dBm (normal: below -15 is warning)
# If NO-CARRIER or high error count:
# 1. Contact Atman NOC: support@atman.pl or portal.atman.pl
# 2. Request fiber light level check on their patch panel
# 3. Try reseating SFP module on your side
Step 2: Verify L2 connectivity (ARP/MAC)
# If interface is UP but BGP is down, check L2
# Ping the peering partner's IP (BGP neighbor address)
ping -c 5 -M do -s 1472 185.1.x.x
# If ping works: L2 is fine, issue is L3 (BGP config)
# If ping fails: check VLAN tagging
# Check if VLAN tagging is required
ip -d link show eth1
# Look for: vlan protocol 802.1Q id <VLAN_ID>
# If VLAN is needed but not configured:
ip link add link eth1 name eth1.100 type vlan id 100
ip addr add 185.1.x.y/30 dev eth1.100
ip link set eth1.100 up
Step 3: Check MTU alignment
# Test path MTU to the peer
ping -c 5 -M do -s 8972 185.1.x.x
# If this fails but -s 1472 works: MTU mismatch
# Set interface MTU to match the cross-connect
ip link set eth1 mtu 9000
# Or if the peer uses 1500, set yours to match
ip link set eth1 mtu 1500
# Make it persistent (Debian/Ubuntu)
# In /etc/network/interfaces:
# auto eth1
# iface eth1 inet static
# mtu 9000
Step 4: Verify BGP configuration
# BIRD: check config syntax
birdc configure check
# Expected: "Configuration OK"
# Verify neighbor address matches the cross-connect IP
birdc show protocols all atman_peer | grep "Neighbor address"
# Verify AS number matches Atman's assignment
# FRRouting: verify config
vtysh -c "show running-config" | grep -A 10 "neighbor 185.1"
# Check: remote-as, password (if MD5 auth), update-source
# If using MD5 authentication, verify the password matches
# (common failure after password rotation on either side)
Step 5: Reset the BGP session
# BIRD: restart the protocol
birdc restart atman_peer
# FRRouting: clear the session
vtysh -c "clear bgp neighbor 185.1.x.x"
# Wait for session to establish (up to 90 seconds for hold timer)
watch -n 5 'birdc show protocols atman_peer'
# Expected: State changes from Active → OpenSent → OpenConfirm → Established
Step 6: Contact Atman NOC if physical or remote issue
If steps 1-5 don’t resolve it:
To: support@atman.pl (or via portal.atman.pl)
Subject: Cross-connect issue - [Your Rack ID] - BGP session down
Body:
- Cross-connect ID: [from your Atman contract]
- Your side: interface UP, SFP light levels normal
- Remote peer: [partner name, rack ID if known]
- Issue: BGP session does not establish, no L2 connectivity / intermittent packet loss
- Request: Please verify fiber patch integrity and contact remote side
Validation
# 1. Verify BGP session is Established
birdc show protocols atman_peer | grep -i state
# Expected: "BGP state: Established"
# FRRouting: vtysh -c "show bgp summary" | grep 185.1
# Expected: Shows prefix count (not Idle/Active)
# 2. Verify routes are being received
birdc show route protocol atman_peer | wc -l
# Expected: >0 routes received from peer
# 3. Verify routes are being advertised
birdc show route export atman_peer | wc -l
# Expected: your prefixes are being sent to the peer
# 4. Verify no packet loss on the cross-connect
ping -c 100 -i 0.1 185.1.x.x | tail -3
# Expected: 0% packet loss
# 5. Verify no CRC errors accumulating
ethtool -S eth1 | grep crc
# Expected: count not increasing (check twice, 1 minute apart)
# 6. Monitor session stability for 30 minutes
watch -n 60 'birdc show protocols atman_peer | grep "Since"'
# Expected: timestamp doesn't change (session stays up)
If the BGP session shows Established, routes are flowing in both directions, and the session stays stable for 30+ minutes, the peering is restored. Set up monitoring on the BGP state (e.g., bird_protocol_up metric in Prometheus or a simple cron check) to get alerted before traffic impact next time.
A flapping BGP session means your traffic is either blackholing completely or falling back to expensive transit links. For networks with only one upstream at Atman, this is a full outage. For multi-homed setups, it still means degraded performance and higher transit bills until the peering recovers. The difference between 5-minute resolution and multi-hour debugging is having this procedure ready and knowing who to call at Atman NOC.
Running infrastructure in Polish datacenters?
Book a free 30-minute call. We operate networks at Atman, 3S, Exea, and Beyond with full BGP, failover design, and 24/7 monitoring.