Modelagem de tráfego no Linux com HTB: resultados estranhos

Question

Estou tentando ter uma limitação de largura de banda simples configurada em um servidor Linux e eu estou correndo para o que parece ser algo muito estranho, apesar de um aparentemente trivial config.

Quero moldar o tráfego que chega a um IP de cliente específico (10.41.240.240) em um disco rígido máximo de 75 Kbit / s. Veja como eu configurei a modelagem:

# tc qdisc add dev eth1 root handle 1: htb default 1 r2q 1

# tc class add dev eth1 parent 1: classid 1:1 htb rate 75Kbit
# tc class add dev eth1 parent 1:1 classid 1:10 htb rate 75kbit 

# tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip dst
10.41.240.240 flowid 1:10

Para testar, inicio um download de arquivo via HTTP a partir da dita máquina cliente e meço a velocidade resultante olhando para Kb / s no Firefox.

Agora, o comportamento é bastante intrigante: o DL começa em cerca de 10Kbytes / s e prossegue para pegar velocidade até estabilizar a cerca de 75Kbytes / s (Kilobytes, não Kilobits como configurado!). Então, se eu iniciar vários downloads paralelos desse mesmo arquivo, cada download estabilizará a cerca de 45Kbytes / s; a velocidade combinada desses downloads excede em muito o máximo configurado.

Aqui está o que eu recebo quando sondando o tc para informações de depuração

[root@kup-gw-02 /]# tc -s qdisc show dev eth1
qdisc htb 1: r2q 1 default 1 direct_packets_stat 1
 Sent 17475717 bytes 1334 pkt (dropped 0, overlimits 2782 requeues 0)
 rate 0bit 0pps backlog 0b 12p requeues 0

[root@kup-gw-02 /]# tc -s class show dev eth1
class htb 1:1 root rate 75000bit ceil 75000bit burst 1608b cburst 1608b
 Sent 14369397 bytes 1124 pkt (dropped 0, overlimits 0 requeues 0)
 rate 577896bit 5pps backlog 0b 0p requeues 0
 lended: 1 borrowed: 0 giants: 1938
 tokens: -205561 ctokens: -205561

class htb 1:10 parent 1:1 prio 0 **rate 75000bit ceil 75000bit** burst 1608b cburst 1608b
 Sent 14529077 bytes 1134 pkt (dropped 0, overlimits 0 requeues 0)
 **rate 589888bit** 5pps backlog 0b 11p requeues 0
 lended: 1123 borrowed: 0 giants: 1938
 tokens: -205561 ctokens: -205561

O que eu não posso para a vida de mim entender é isso: como é que eu recebo uma "taxa de 589888bit 5pps" com uma configuração de "rate 75000bit ceil 75000bit"? Por que a taxa efetiva fica muito mais alta que a taxa configurada? O que estou fazendo de errado? Por que está se comportando do jeito que é?

Por favor me ajude, estou perplexo. Obrigado pessoal.

    

Answer 1

Acho que meio que resolvi o problema: eu precisava amarrar os qdiscs / classes a um dispositivo IMQ em vez de um dispositivo ETH. Depois que fiz isso, o shaper começou a trabalhar.

No entanto,

Enquanto eu poderia fazer com que o shaper limitasse o tráfego de entrada para uma máquina, eu não conseguiria dividir o tráfego de forma justa (mesmo que eu tenha anexado um SFQ ao meu HTB).

O que aconteceu foi isto: eu iniciei um download; ficou limitado a 75Kbyte / s. Agora, quando eu iniciei um segundo download, em vez de dividir o tráfego entre as duas sessões de DL (35Kbyte / s + 35Kbyte / s), ele apenas perdeu velocidade na primeira sessão e deu à sessão dois uns escassos 500b / s. Depois de alguns minutos, a divisão se estabeleceu em algo como 65Kbyte / s + 10Kbyte / s. indignada Isso não é justo! :)

Então eu desmontei minha configuração, fui em frente e configurei o ClearOS 5.2 (uma distribuição Linux com um sistema de firewall pré-construído) que possui um módulo de modelador de tráfego. O módulo usa uma configuração HTB + SFQ muito semelhante ao que configurei manualmente.

Mesma questão de justiça! O limite geral é bem aplicado, mas não há justiça! - dois downloads compartilham na mesma proporção estranha proporção 65/15, em vez de 35/35.

Alguma idéia, pessoal?

    

Answer 2

Tente usar este exemplo:

# tc qdisc add dev eth1 root handle 1: htb default 10

# tc class add dev eth1 parent 1: classid 1:1 htb rate 75Kbit
# tc class add dev eth1 parent 1:1 classid 1:10 htb rate 1Kbit ceil 35Kbit
# tc class add dev eth1 parent 1:1 classid 1:20 htb rate 35kbit

# tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10
# tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10

# tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 \
    match ip dst 10.41.240.240 flowid  1:20

Isso cria um bucket htb com limite de taxa de 75Kbit / s, então cria dois sfq (um qdisc de exibição justa) abaixo dele.

Por padrão, todos estarão na primeira fila, com uma taxa garantida de 1Kbit e uma taxa máxima de 30Kbit. Agora, o seu ip de 10.41.240.240 será garantido 35Kbit e pode levar até 75Kbit se o tráfego não selecionado for utilizado. Duas conexões de 0,240 devem ficar na média e ser as mesmas por conexão, e uma conexão entre um .240 e um não .240 será paralela em uma proporção de 35: 1 entre as filas.

Eu vejo que isso está morto desde Abr ... então espero que esta informação ainda seja valiosa para você.

    

Answer 3

Isso pode estar relacionado a isso:

De: link

Um aviso para os usuários do Xen

Se você estiver executando a modelagem de tráfego em seu dom0 e a modelagem de tráfego não estiver limitando o tráfego de saída corretamente, isso pode ser devido a "descarregamento de soma de verificação" em seu (s) domU (s). Verifique a saída de "shorewall show tc". Aqui está um trecho da saída desse comando:

class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 1500 rate 76000bit ceil 230000bit burst 1537b/8 mpu 0b overhead 0b cburst 1614b/8 mpu 0b overhead 0b level 0 
 Sent 559018700 bytes 75324 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 299288bit 3pps backlog 0b 0p requeues 0 
 lended: 53963 borrowed: 21361 giants: 90174
 tokens: -26688 ctokens: -14783

Existem dois problemas óbvios na saída acima:

• A taxa (299288) é consideravelmente maior que o teto (230000).
• Há um grande número (90.174) de gigantes relatados.

Esse problema será corrigido desativando-se o "descarregamento da soma de verificação" em seu (s) domUs usando o utilitário ethtool. Veja um dos artigos do Xen para instruções.