Google Cloud Cross-Cloud Interconnect sesja BGP flapping: limit ogłaszanych tras i niestabilność peeringu

Objawy

Logi Cloud Router pokazują oscylację sesji BGP:

BGP peer aws-peer on interface interconnect-attachment-0 changed state from ESTABLISHED to IDLE
BGP peer aws-peer on interface interconnect-attachment-0 changed state from IDLE to ESTABLISHED

Te przejścia powtarzają się co 30-90 sekund. Trasy ogłaszane ze strony zdalnej pojawiają się i znikają w tablicy routingu VPC:

gcloud compute routes list --filter="network=my-vpc" --format="table(destRange, nextHopIp, priority)"

Pokazuje trasy migające między kolejnymi uruchomieniami polecenia.

Cloud Logging ujawnia przyczynę resetu:

Received BGP notification: cease/administrative reset

Lub:

BGP session reset: hold timer expired

Łączność między chmurami jest przerywana - część żądań przechodzi, inne kończą się timeout w zależności od tego, czy trasy są aktualnie zainstalowane.

Przyczyna

Niestabilność sesji BGP (flapping) na Cross-Cloud Interconnect jest zwykle spowodowana jednym z poniższych problemów:

1. Przekroczony limit ogłaszanych tras. Cloud Router ma domyślny limit 100 poznanych tras na sesję BGP. Gdy strona zdalna (AWS) ogłasza więcej niż 100 prefiksów, Cloud Router resetuje sesję, aby chronić się przed przepełnieniem tablicy routingu. Sesja ustanawia się ponownie, poznaje trasy, trafia na limit i resetuje w pętli.

2. Konflikt ASN między Cloud Router a stroną AWS. Jeśli obie strony przypadkowo używają tego samego ASN (np. obie 65000), BGP wykrywa pętlę AS w otrzymanych aktualizacjach i odrzuca wszystkie trasy. Niektóre implementacje resetują sesję, gdy wszystkie trasy są odrzucone.

3. Niezgodność hold timer. GCP Cloud Router domyślnie używa 60-sekundowego hold timer (20-sekundowy keepalive). Jeśli strona AWS używa krótszego hold timer lub jeśli pakiety keepalive są opóźnione przez przeciążenie na interconnect, hold timer wygasa i sesja pada.

4. Niezgodność MTU na VLAN attachment. VLAN attachment Cross-Cloud Interconnect obsługuje do 1500 bajtów MTU dla warstwy sterowania BGP. Jeśli MTU jest błędnie skonfigurowane (np. ustawione na 1440 dla kompatybilności z IPsec), duże wiadomości BGP UPDATE przenoszące wiele tras są fragmentowane lub odrzucane po cichu, powodując, że peer uznaje sesję za martwą.

5. Zbyt czuły BFD (Bidirectional Forwarding Detection). Jeśli BFD jest włączony z agresywnymi timerami (np. interwał 300ms, mnożnik 3x = wykrycie w 900ms), każde krótkotrwałe przeciążenie lub mikropętla powoduje, że BFD deklaruje łącze jako down i zrywa sesję BGP, mimo że fizycznie łącze jest sprawne.

Rozwiązanie

Krok 1: Sprawdzenie aktualnego statusu sesji BGP i liczby tras

gcloud compute routers get-status my-cloud-router \
  --region us-east4 \
  --format="yaml(result.bgpPeerStatus)"

Sprawdź wartość numLearnedRoutes dla każdego peera. Jeśli jest na poziomie 100 lub blisko, trafiłeś na limit tras.

Krok 2: Zwiększenie limitu poznanych tras

Jeśli problem dotyczy liczby tras, zwiększ limit na Cloud Router:

gcloud compute routers update-bgp-peer my-cloud-router \
  --peer-name aws-peer \
  --region us-east4 \
  --set-advertisement-mode custom \
  --set-advertisement-ranges 10.0.0.0/8

# Increase the route limit (requires updating the router)
gcloud compute routers update my-cloud-router \
  --region us-east4 \
  --set-bgp-peer-asn 65001 \
  --bgp-peer-name aws-peer

Alternatywnie, poproś o zwiększenie limitu (quota) maksymalnej liczby poznanych tras:

gcloud compute routers update my-cloud-router \
  --region us-east4 \
  --set-peer-ip-address 169.254.10.2 \
  --set-peer-asn 65001

Po stronie AWS użyj sumaryzacji tras, aby zmniejszyć liczbę ogłaszanych prefiksów:

# On AWS Transit Gateway, configure summarization
aws ec2 create-transit-gateway-route \
  --transit-gateway-route-table-id tgw-rtb-0abc123 \
  --destination-cidr-block 10.0.0.0/8 \
  --transit-gateway-attachment-id tgw-attach-0def456

Krok 3: Weryfikacja konfiguracji ASN

Sprawdzenie ASN Cloud Router:

gcloud compute routers describe my-cloud-router \
  --region us-east4 \
  --format="value(bgp.asn)"

Sprawdzenie ASN peera skonfigurowanego na Cloud Router:

gcloud compute routers describe my-cloud-router \
  --region us-east4 \
  --format="yaml(bgpPeers[].peerAsn)"

Weryfikacja po stronie AWS:

aws directconnect describe-virtual-interfaces \
  --query 'virtualInterfaces[?virtualInterfaceName==`my-cross-cloud-vif`].{ASN:asn,AmazonASN:amazonSideAsn}' \
  --output table

ASN Cloud Router musi się różnić od ASN po stronie AWS. Jeśli są takie same, zaktualizuj jedną stronę:

# Change Cloud Router ASN (requires recreation)
gcloud compute routers delete my-cloud-router --region us-east4 --quiet

gcloud compute routers create my-cloud-router \
  --region us-east4 \
  --network my-vpc \
  --asn 65010

Krok 4: Wyrównanie hold timer

Sprawdzenie aktualnego hold timer na Cloud Router:

gcloud compute routers describe my-cloud-router \
  --region us-east4 \
  --format="yaml(bgp.keepaliveInterval)"

Ustawienie spójnego hold timer. GCP Cloud Router wspiera konfigurację interwału keepalive (hold timer = 3x keepalive):

gcloud compute routers update my-cloud-router \
  --region us-east4 \
  --keepalive-interval 20

To ustawia hold timer na 60 sekund (3 x 20). Weryfikacja, że strona AWS używa zgodnego lub dłuższego hold timer:

aws directconnect describe-bgp-peers \
  --query 'bgpPeers[*].{Peer:bgpPeerId,State:bgpPeerState,ASN:asn}' \
  --output table

W konfiguracji routera AWS upewnij się, że hold timer wynosi co najmniej 60 sekund (domyślna wartość w większości konfiguracji AWS).

Krok 5: Sprawdzenie i naprawa MTU VLAN attachment

gcloud compute interconnects attachments describe my-attachment \
  --region us-east4 \
  --format="value(mtu)"

Dla Cross-Cloud Interconnect MTU powinno wynosić 1440 lub 1500 w zależności od typu interconnect. Jeśli wiadomości BGP UPDATE są duże (wiele tras), upewnij się, że MTU pozwala na dostarczenie bez fragmentacji:

gcloud compute interconnects attachments update my-attachment \
  --region us-east4 \
  --mtu 1500

Test, czy pakiety BGP keepalive i update przechodzą bez fragmentacji:

# From a test instance on the interconnect subnet
ping -M do -s 1472 169.254.10.1

Jeśli to zawodzi, zmniejsz do 1440:

ping -M do -s 1412 169.254.10.1

Krok 6: Dostrojenie lub wyłączenie BFD

Jeśli BFD powoduje przedwczesne zrywanie sesji, zwiększ interwał wykrywania:

gcloud compute routers update-bgp-peer my-cloud-router \
  --peer-name aws-peer \
  --region us-east4 \
  --bfd-min-receive-interval 1000 \
  --bfd-min-transmit-interval 1000 \
  --bfd-multiplier 5

To ustawia czas wykrycia BFD na 5 sekund (1000ms x 5), co jest tolerancyjne wobec krótkotrwałych przeciążeń, jednocześnie wykrywając rzeczywiste awarie łącza szybciej niż BGP hold timer.

Aby wyłączyć BFD całkowicie podczas diagnostyki:

gcloud compute routers update-bgp-peer my-cloud-router \
  --peer-name aws-peer \
  --region us-east4 \
  --bfd-session-initialization-mode disabled

Krok 7: Monitoring logów Cloud Router pod kątem pozostałych problemów

gcloud logging read '
  resource.type="gce_router"
  AND resource.labels.router_id="my-cloud-router"
  AND severity>=WARNING
  AND timestamp>="2026-07-14T00:00:00Z"
' --project my-project --limit 50 --format="table(timestamp, severity, textPayload)"

Walidacja

Potwierdzenie, że sesja BGP jest stabilna przez ponad 10 minut:

gcloud compute routers get-status my-cloud-router \
  --region us-east4 \
  --format="yaml(result.bgpPeerStatus[].{name:name,status:status,uptimeSeconds:uptimeSeconds,numLearnedRoutes:numLearnedRoutes})"

Oczekiwany wynik:

- name: aws-peer
  status: UP
  uptimeSeconds: '600'
  numLearnedRoutes: 45

Weryfikacja, że liczba tras jest spójna i poniżej limitu:

gcloud compute routes list \
  --filter="network=my-vpc AND nextHopIp:169.254.*" \
  --format="table(destRange, nextHopIp, priority)" | wc -l

Uruchom to polecenie 5 razy w ciągu 5 minut - liczba powinna pozostać taka sama.

Sprawdzenie logów Cloud Router pod kątem niestabilności w ostatnich 15 minutach:

gcloud logging read '
  resource.type="gce_router"
  AND textPayload:"changed state"
  AND timestamp>="2026-07-14T08:45:00Z"
' --project my-project --limit 10

Oczekiwany wynik: brak wyników (brak zmian stanu).

Test łączności end-to-end między chmurami:

# From GCP instance to AWS instance
for i in $(seq 1 10); do
  ping -c 1 -W 2 10.0.1.50 && echo "OK" || echo "FAIL"
  sleep 5
done

Wszystkie 10 prób powinno zwrócić OK bez przerywanych awarii.

Potrzebujesz pomocy z łącznością multi-cloud?

Umów darmową 30-minutową rozmowę. Zdiagnozujemy problem z połączeniem i zarekomendujemy właściwe rozwiązanie.

Umów rozmowę