Назад | Перейти на главную страницу

Машина FreeBSD не отвечает на несколько первых пакетов потока

У меня есть две машины, работающие как обратные прокси-кеши / балансировщики нагрузки перед сайтом, который я администрирую. Недавно в часы пик я столкнулся с проблемой, когда первые несколько пакетов из любого потока пакетов (ICMP, UDP, TCP и т. Д.) Прибывают на машину, но не отвечают.

Вот симптом с точки зрения того, кто пингует машины:

PING X.X.X.X (X.X.X.X): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
64 bytes from X.X.X.X: icmp_seq=11 ttl=62 time=47.515 ms
64 bytes from X.X.X.X: icmp_seq=12 ttl=62 time=46.108 ms
64 bytes from X.X.X.X: icmp_seq=13 ttl=62 time=48.893 ms
64 bytes from X.X.X.X: icmp_seq=14 ttl=62 time=47.466 ms
64 bytes from X.X.X.X: icmp_seq=15 ttl=62 time=49.679 ms
64 bytes from X.X.X.X: icmp_seq=16 ttl=62 time=50.011 ms
64 bytes from X.X.X.X: icmp_seq=17 ttl=62 time=49.324 ms
64 bytes from X.X.X.X: icmp_seq=18 ttl=62 time=48.989 ms
64 bytes from X.X.X.X: icmp_seq=19 ttl=62 time=51.003 ms
64 bytes from X.X.X.X: icmp_seq=20 ttl=62 time=48.612 ms

Вот представление HTTP-сеанса через tcpdump на затронутом компьютере (X.X.X.X -> затронутый компьютер, C.C.C.C -> клиент делает запрос):

21:46:27.105396 IP C.C.C.C.62425 > X.X.X.X.80: Flags [S], seq 139436485, win 65535, options [mss 1380,nop,wscale 3,nop,nop,TS val 398010008 ecr 0,sackOK,eol], length 0
21:46:28.032300 IP C.C.C.C.62425 > X.X.X.X.80: Flags [S], seq 139436485, win 65535, options [mss 1380,nop,wscale 3,nop,nop,TS val 398010017 ecr 0,sackOK,eol], length 0
21:46:28.032337 IP X.X.X.X.80 > C.C.C.C.62425: Flags [S.], seq 1108838018, ack 139436486, win 65535, options [mss 1380,nop,wscale 9,sackOK,TS val 1918451162 ecr 398010017], length 0
21:46:28.064417 IP C.C.C.C.62425 > X.X.X.X.80: Flags [.], ack 1, win 65535, options [nop,nop,TS val 398010018 ecr 1918451162], length 0
21:46:28.064438 IP C.C.C.C.62425 > X.X.X.X.80: Flags [P.], ack 1, win 65535, options [nop,nop,TS val 398010018 ecr 1918451162], length 160
21:46:28.165372 IP X.X.X.X.80 > C.C.C.C.62425: Flags [.], ack 161, win 128, options [nop,nop,TS val 1918451296 ecr 398010018], length 0
21:46:28.165933 IP X.X.X.X.80 > C.C.C.C.62425: Flags [.], ack 161, win 128, options [nop,nop,TS val 1918451296 ecr 398010018], length 1368
21:46:28.219978 IP C.C.C.C.62425 > X.X.X.X.80: Flags [.], ack 1369, win 65535, options [nop,nop,TS val 398010019 ecr 1918451296], length 0
21:46:28.220001 IP X.X.X.X.80 > C.C.C.C.62425: Flags [.], ack 161, win 128, options [nop,nop,TS val 1918451350 ecr 398010019], length 1368
21:46:28.220011 IP X.X.X.X.80 > C.C.C.C.62425: Flags [.], ack 161, win 128, options [nop,nop,TS val 1918451350 ecr 398010019], length 1368
21:46:28.288178 IP C.C.C.C.62425 > X.X.X.X.80: Flags [.], ack 4105, win 65493, options [nop,nop,TS val 398010020 ecr 1918451350], length 0
21:46:28.288196 IP X.X.X.X.80 > C.C.C.C.62425: Flags [.], ack 161, win 128, options [nop,nop,TS val 1918451418 ecr 398010020], length 1368
21:46:28.288203 IP X.X.X.X.80 > C.C.C.C.62425: Flags [.], ack 161, win 128, options [nop,nop,TS val 1918451418 ecr 398010020], length 1368
21:46:28.288210 IP X.X.X.X.80 > C.C.C.C.62425: Flags [.], ack 161, win 128, options [nop,nop,TS val 1918451418 ecr 398010020], length 1368
21:46:28.288217 IP X.X.X.X.80 > C.C.C.C.62425: Flags [.], ack 161, win 128, options [nop,nop,TS val 1918451418 ecr 398010020], length 1368
21:46:28.333968 IP C.C.C.C.62425 > X.X.X.X.80: Flags [.], ack 6841, win 65493, options [nop,nop,TS val 398010020 ecr 1918451418], length 0
21:46:28.333986 IP X.X.X.X.80 > C.C.C.C.62425: Flags [.], ack 161, win 128, options [nop,nop,TS val 1918451464 ecr 398010020], length 1368
21:46:28.333994 IP X.X.X.X.80 > C.C.C.C.62425: Flags [.], ack 161, win 128, options [nop,nop,TS val 1918451464 ecr 398010020], length 1368
21:46:28.338939 IP C.C.C.C.62425 > X.X.X.X.80: Flags [.], ack 9577, win 65493, options [nop,nop,TS val 398010020 ecr 1918451418], length 0
21:46:28.338955 IP X.X.X.X.80 > C.C.C.C.62425: Flags [.], ack 161, win 128, options [nop,nop,TS val 1918451469 ecr 398010020], length 1368
21:46:28.338962 IP X.X.X.X.80 > C.C.C.C.62425: Flags [.], ack 161, win 128, options [nop,nop,TS val 1918451469 ecr 398010020], length 1368
21:46:28.349943 IP C.C.C.C.62425 > X.X.X.X.80: Flags [.], ack 12313, win 65535, options [nop,nop,TS val 398010021 ecr 1918451464], length 0
21:46:28.354190 IP C.C.C.C.62425 > X.X.X.X.80: Flags [.], ack 15049, win 65535, options [nop,nop,TS val 398010021 ecr 1918451469], length 0
21:46:28.354206 IP X.X.X.X.80 > C.C.C.C.62425: Flags [P.], ack 161, win 128, options [nop,nop,TS val 1918451484 ecr 398010021], length 8
21:46:28.393441 IP C.C.C.C.62425 > X.X.X.X.80: Flags [.], ack 15057, win 65535, options [nop,nop,TS val 398010021 ecr 1918451484], length 0
21:46:28.393452 IP C.C.C.C.62425 > X.X.X.X.80: Flags [F.], seq 161, ack 15057, win 65535, options [nop,nop,TS val 398010021 ecr 1918451484], length 0
21:46:28.393467 IP X.X.X.X.80 > C.C.C.C.62425: Flags [.], ack 162, win 128, options [nop,nop,TS val 1918451524 ecr 398010021], length 0
21:46:28.393481 IP X.X.X.X.80 > C.C.C.C.62425: Flags [F.], seq 15057, ack 162, win 128, options [nop,nop,TS val 1918451524 ecr 398010021], length 0
21:46:28.445126 IP C.C.C.C.62425 > X.X.X.X.80: Flags [.], ack 15057, win 65535, options [nop,nop,TS val 398010021 ecr 1918451524], length 0
21:46:28.445138 IP C.C.C.C.62425 > X.X.X.X.80: Flags [.], ack 15058, win 65535, options [nop,nop,TS val 398010021 ecr 1918451524], length 0

Две машины находятся в пуле CARP, одна из которых является активной, а другая - резервной. Оборудование и конфигурация машин идентичны. Проблема затрагивает только активную машину и видна для трафика, идущего на IP-адреса выделенных машин и на плавающий IP-адрес CARPed. Замена активного на резервный и наоборот устраняет проблему, поэтому я почти уверен, что это не проблема оборудования.

Они используют pf в качестве межсетевого экрана и для трафика NAT для машин, находящихся за ними.

Они работают под управлением FreeBSD 8.0-RELEASE-p5. Хотя их ядра построены по индивидуальному заказу, это только для добавления необходимых битов для использования CARP. Конфиги ядра следующие:

include GENERIC

ident LOADBALANCER

device pf
device pflog
device pfsync
device carp

Сетевая карта - Intel 82574L, использующая драйвер em.

Какие-нибудь подсказки?

networking ip freebsd pf packetloss

Оказывается, проблема была в pf.

pf во FreeBSD по умолчанию ограничивает количество записей в таблице состояний до 10 000. Адаптивные тайм-ауты продолжались большую часть времени, но не справлялись в часы пик.