Fazendo o despejo TCP sem perda de pacotes

Question

Como fazer um despejo TCP onde é garantido que todos os pacotes que realmente passam pela rede são capturados e nada é perdido?

Detalhes: Temos um problema com o fornecedor terceirizado que fornece uma solução em cima da pilha SCTP, que ele também implementa.
Com uma taxa de transferência bastante alta (52.000 mensagens / s, o tamanho médio da mensagem é de 500 bytes), o link SCTP é interrompido.
Acreditamos que o erro esteja na pilha SCTP do fornecedor.
Mas o fornecedor diz que isso acontece porque o SCTP stack envia uma mensagem, não recebe ACK, envia um número de retransmissões, não recebe ACKs e fecha o link SCTP.
Então o vendedor diz, essa é a rede que é culpada, porque perde pacotes.

Nos despejos TCP em ambos os lados, cliente e servidor, vemos que as mensagens originais chegam ao servidor e veem que o servidor não responde com o ACK. Mas o fornecedor diz que os despejos TCP não são confiáveis, que ao capturar um despejo TCP, alguns pacotes podem não ser capturados, porque a biblioteca libpcap funciona somente dentro de um encadeamento de hardware, sua potência pode não ser suficiente para registrar todos os pacotes. >

Dados técnicos: 52 000 mensagens / seg, o tamanho médio da mensagem é de 500 bytes, portanto, 26 MB / seg no total, são utilizados 4 links SCTP. Hardware: CPU E5-2670, 2,6 GHz, 8 threads HW
Rede: 10 GBit, o tráfego é entre os blades HP, que estão localizados em um rack.
RHEL 6.

    

Answer 1

Em sua quantidade de tráfego, eu diria que o libpcap não deve ter problemas com pacotes descartados, a menos que você tenha uma configuração particularmente ineficiente. Se você estiver usando tcpdump para captura, ele relatará a quantidade de pacotes descartados em sua linha de saída final. Se você ver pacotes descartados, você pode querer aumentar o tamanho do buffer do tcpdump fornecendo a opção -B para defina um valor consideravelmente maior que o padrão de 2 MB.

No entanto, você pode querer olhar para PF_RING :

Who needs PF_RING™?

Basically everyone who has to handle many packets per second. The term ‘many’ changes according to the hardware you use for traffic analysis. It can range from 80k pkt/sec on a 1,2GHz ARM to 14M pkt/sec and above on a low-end 2,5GHz Xeon. PF_RING™ not only enables you to capture packets faster, it also captures packets more efficiently preserving CPU cycles. Just to give you some figures you can see how fast nProbe, a NetFlow v5/v9 probe, can go using PF_RING™, or have a look at the tables below.

10 Gigabit tests performed on a Core2Duo 1.86 GHz and a low-end Xeon 2,5 Ghz

                                    ixgbe 
            Application                                 Rate 
pfcount (RX, with PF_RING™ DNA)        11 Mpps (Core2Duo), 14.8 Mpps (Xeon) 
pfsend (TX, with PF_RING™ DNA)         11 Mpps (Core2Duo), 14.8 Mpps (Xeon)

O Guia do usuário do PF_RING explica como compilar e configurar habilitado para PF_RING bibliotecas libpcap, se você insistir em usar aplicativos libpcap para captura de pacotes.