Atman cross-connect sesja BGP down: diagnoza niestabilności i przywrócenie peeringu
Przywrócenie sesji BGP przez cross-connect Atman, gdy peering pada z powodu usterek warstwy fizycznej, problemów MTU lub wygaśnięcia hold timer.
Jeśli planujesz suwerenną infrastrukturę EU i dobór datacenter, zobacz naszą stronę EU sovereign cloud. Dla realnego projektu migracji z uwzględnieniem lokalizacji datacenter w EU zobacz case study o przeniesieniu infrastruktury do EU.
Objawy
Sesja BGP peering jest w stanie Idle, Active lub oscyluje między Established a 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
Jeśli interfejs pokazuje NO-CARRIER, problem jest fizyczny (warstwa L1). Jeśli interfejs jest UP, ale BGP jest w stanie Active lub Idle, usterka dotyczy warstwy L3 (konfiguracja, MTU lub strona zdalna).
Przyczyna
Awarie sesji BGP na cross-connectach Atman mają zwykle jedną z poniższych przyczyn:
- Usterka warstwy fizycznej. Patchcord światłowodowy między Twoją szafą a szafą partnera peeringowego został uszkodzony, odłączony, albo moduł SFP uległ awarii. NOC Atman może zweryfikować poziomy sygnału na swoim panelu krosowym.
- Niezgodność MTU. Cross-connecty Atman domyślnie obsługują jumbo frames (9000 bajtów), ale jeśli jedna strona ma skonfigurowane 1500, a druga 9000, wiadomości BGP OPEN (które mieszczą się w 1500) nawiążą sesję na chwilę, po czym większe wiadomości UPDATE zostaną po cichu odrzucone, co spowoduje wygaśnięcie hold timer.
- Wygaśnięcie hold timer z powodu utraty pakietów. Jeśli cross-connect przepuszcza część ruchu, ale gubi pakiety sporadycznie (brudne włókno, błędy CRC), pakiety keepalive są tracone i sesja pada po upływie hold timer (domyślnie 90s).
- Rekonfiguracja strony zdalnej. Partner peeringowy zmienił konfigurację BGP (błędny ASN, zmiana hasła, usunięcie Twojego prefiksu z polityki).
- Niezgodność tagowania VLAN. Jeśli cross-connect wymaga konkretnego tagu VLAN (niektóre cross-connecty Atman są tagowane, szczególnie w układach multi-tenant), niezgodność uniemożliwi jakąkolwiek łączność L2.
Naprawa
Krok 1: Weryfikacja warstwy fizycznej (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
Krok 2: Weryfikacja łączności L2 (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
Krok 3: Sprawdzenie zgodności MTU
# 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
Krok 4: Weryfikacja konfiguracji BGP
# 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)
Krok 5: Reset sesji BGP
# 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
Krok 6: Kontakt z NOC Atman w przypadku problemów fizycznych lub po stronie zdalnej
Jeśli kroki 1-5 nie rozwiązują problemu:
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
Walidacja
# 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)
Jeśli sesja BGP pokazuje Established, trasy przepływają w obu kierunkach i sesja jest stabilna przez ponad 30 minut - peering jest przywrócony. Skonfiguruj monitoring stanu BGP (np. metrykę bird_protocol_up w Prometheus albo prosty cron check), żeby dostać alert zanim ruch ucierpi następnym razem.
Niestabilna sesja BGP oznacza, że Twój ruch albo wpada w blackhole, albo spada na drogie łącza tranzytowe. Dla sieci z jednym upstreamem w Atman to pełna awaria. Dla setupów multi-homed to wciąż degradacja wydajności i wyższe rachunki za tranzyt, dopóki peering nie wróci. Różnica między 5-minutową naprawą a wielogodzinnym debugowaniem to gotowa procedura i wiedza, do kogo dzwonić w NOC Atman.
Prowadzisz infrastrukturę w polskich datacenter?
Umów się na bezpłatną 30-minutową rozmowę. Utrzymujemy sieci w Atman, 3S, Exea i Beyond z pełnym BGP, projektowaniem failover i monitoringiem 24/7.