Pergunta

Estamos executando um Debian com um kernel 2.6.16, com iptables habilitado. O sistema está executando uma custom made proxy HTTP, que é submetido a uma carga leve (que funciona bem com a mesma carga em outros sites). O sistema é composto de 4 servidores que são precedidas por um balanceador de carga com IP virtual, que é precedido por uma série de 4 máquinas ISA 2004, de modo a topologia básica é:

Client -> ISA [1-4] -> Load Balancer -> Nossa Proxy [1-4] -> A Internet

Ocasionalmente, o ISA vai nos enviar um pacote SYN, à qual não SYN-ACK está sendo enviado. Ele tentará novamente após 3 segundos, e uma terceira vez depois de mais de 6 segundos, após o que irá relatar o baixo proxy, e mudar para conexão direta. Durante este tempo, ou seja, antes, entre e após esses 3 SYNs, outros SYNs da mesma ISA vêm e são respondidas com sucesso.

Um problema muito semelhante está sendo relatado por outros (sem solução, no entanto):

Todos vindo de um sabor de Linux chamado CentOS. É da peculiaridade é em ter iptables ativado por padrão.

http://www.linuxhelpforum.com/showthread.php?t = 931912 & = modo linear http://www.centos.org/modules/newbb/viewtopic. php? topic_id = 16147

Quase a mesma: mas um pouco diferente: http: //www.linuxquestions.org/questions/linux-networking-3/tcp-handshake-fails-synack-ignored-by-system.-637171/

Também parece ser relevante: http://groups.google.com/group/ comp.os.linux.networking / browse_thread / thread / b1c000e2d65e0034

I iptables suspeitos para ser um culpado, mas qualquer feedback adicional será bem-vinda.

Foi útil?

Solução

Olhe para o segundo parâmetro para o ouvir chamada, como mencionado no primeiro link que você postou. É o número máximo de pendente (ainda não aceita) conexões. De acordo com a ouvir (2) página homem, se a retransmissão suporta o protocolo (TCP faz), a solicitação de conexão será descartado quando a fila está cheia (esperando uma posterior retransmissão que irá criar a conexão se há espaço suficiente na fila novamente ).

Outras dicas

Na verdade, as iptables acabou por ser o culrpit, com a regra de que pacotes descartados inválido. Nós ainda não sabemos ao certo o que fez iptables para pensar essas SYNs eram inválidos (sem TIME_WAIT com certeza, uma vez que não tem qualquer tipo de tráfego com as mesmas portas de origem durante pelo menos 30 minutos antes das gotas).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top