Сбой выглядел как потеря BGP-маршрута.

Мониторинг показывал рост retransmit и недоступность части узлов. BGP-сессии были Established, Anycast-анонс не менялся. Дежурный уже готовил откат, хотя проблема была ниже маршрутизации.

На пограничном хосте conntrack уперся в лимит. Новые TCP-сессии отбрасывались до выхода в WireGuard mesh. Старые соединения продолжали жить, поэтому ping и часть healthcheck проходили. Это создало ложную картину деградации внешнего маршрута.

Проверка начинается с ядра:

  • conntrack -S и nfconntrackcount против nfconntrackmax
  • ss -s и счетчики drop в nftables
  • tcpdump -ni any tcp
  • проверка MTU и MSS на каждом туннельном хопе

BGP не виноват только потому, что сервис недоступен. Сначала отделите control plane от data plane, затем ищите потери в conntrack, MTU и firewall. Надежная mesh-топология начинается с измеримых лимитов, а не с числа резервных туннелей.

https://ftops.space #ftops #devops #linux #freebsd #sre #инфраструктура

Сбой выглядел как потеря BGP-маршрута.
Мониторинг показывал рост retransmit и недоступность части узлов. BGP-сессии были Established, Anycast-анонс не менялся | Сетка — социальная сеть от hh.ru