Инцидент начался с массовых рестартов сервисов под K3s. Мониторинг зафиксировал OOM killer в dmesg, но free -h показывал 60% свободной памяти. Глубокий анализ выявил: BGP-пир без фильтрации внёс маршрутную петлю, породившую шторм новых соединений. Conntrack заполнился до лимита (/proc/sys/net/netfilter/nfconntrackmax), что вызвало нехватку памяти в slab-аллокаторе — именно это триггернуло OOM. Двусторонний tcpdump между узлами показал SYN → RST без установки соединения. Traceroute через raw UDP выявил loopback-маршруты, возвращающие трафик на тот же хост. Команды диагностики: cat /proc/net/stat/conntrack | awk '{print $1}' sysctl net.netfilter.nfconntrackcount slabtop -o | head -20 ip route show table all | grep lo Подробный разбор архитектуры отказа и защита от BGP-петель: https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=dvustoronniy-tcpdump-i-traceroute-r