Когда BBR не виноват: детектив сетевого сбоя
Мониторинг кричит о высоком latency, графики показывают просадку throughput, а команда сразу предлагает включить BBR. Это удобная версия, но часто неверная.
На шлюзе первым делом проверяйте conntrack и реальные потери:
- conntrack -S и nf_conntrack_count против nf_conntrack_max
- nstat -az: TcpRetransSegs, TcpExtTCPTimeouts, TcpExtTCPBacklogDrop
- ss -s для очередей и накопившихся TIME_WAIT
- tcpdump -ni any для MSS, фрагментации и повторных SYN
Если conntrack уперся в лимит, BBR не создаст свободные записи. Если MTU или MSS сломаны, смена алгоритма congestion control не исправит черную дыру. Если ethtool -K меняет offload на живом интерфейсе, можно получить краткий, но реальный обрыв линка.
Сначала фиксируйте счетчики до и после инцидента, затем меняйте один параметр и проверяйте результат. sysctl без измерений — это не тюнинг, а гадание. Практика важнее хайпа.
