Limitando a largura de banda da interface com o tc no Linux

Eu tenho um roteador Linux que possui uma interface de 10 GBe no exterior e interfaces Ethernet Gigabit ligadas no interior.

Atualmente, temos um orçamento para 2 GBit / s. Se excedermos essa taxa em mais de 5% da média por um mês, seremos cobrados por toda a capacidade de 10 Gbit / s. Um grande passo em termos de dólares.

Então, eu quero limitar isso a 2 GBit / s na interface de 10 GBe.

O filtro TBF pode ser ideal, mas esse comentário é preocupante.

Em todas as plataformas, exceto Alpha, é capaz de configurar até 1mbit / s de tráfego normal com o mínimo de explosão ideal, enviando dados exatamente nas taxas configuradas.

Devo usar TBF ou algum outro filtro para aplicar essa taxa à interface e como eu faria isso. Não entendo o exemplo dado aqui: HOWTO de Controle de Tráfego

Em particular "Exemplo 9. Criando um TBF de 256kbit / s"

tc qdisc add dev eth0 handle 1:0 root dsmark indices 1 default_index 0
tc qdisc add dev eth0 handle 2:0 parent 1:0 tbf burst 20480 limit 20480 mtu 1514 rate 32000bps

Como é calculada a taxa de 256K bits / s? Neste exemplo, 32000bps = 32k bytes por segundo. Como tc usa bps = bytes por segundo. Acho que burst e limit entram em jogo, mas como você escolheria números sensíveis para atingir a taxa desejada?

Isso não é um erro. Eu testei isso e deu uma taxa perto de 256K, mas não exatamente isso.

EDITAR

Depois de ler e testar bastante, cheguei à conclusão de que o TBF é inadequado por causa da largura de banda envolvida. Quaisquer que sejam as configurações que eu tentei, não consegui que o TBF fornecesse largura de banda> ~ 50Mbit / s. De acordo com lartc.org/lartc.pdf, o método RED é melhor para modelar largura de banda> 100Mbit / s, então tentarei usá-lo.

No entanto, escolhendo o valor a para min (ou seja, tamanho médio da fila em que a marcação se torna uma possibilidade). O exemplo dado é o seguinte:

Você deve definir o mínimo calculando a maior latência aceitável de enfileiramento de base desejada e multiplicá-lo pela sua largura de banda. Por exemplo, no meu link ISDN de 64kbit / s, talvez eu queira uma latência de enfileiramento base de 200ms, então defino min para 1600 bytes.

1. como você escolheria a maior latência aceitável de enfileiramento de base? O exemplo é para 64kbit / s.

2. O que seria aceitável para 2Gbit / s?

1. Você deve escolher a latência de enfileiramento aceitável com base no tipo de tráfego.

   • Por exemplo, para filas de voz com mais de 200 ms já é um problema.
   • Embora o buffer de 500ms para o tráfego ftp / torrent não seja um grande problema.

2. A latência / estratégia de enfileiramento é uma questão de tipo de tráfego e não de velocidade da interface. Por exemplo, VOIP, talvez, não deva ser colocado na fila. Infelizmente, a documentação do tc RED não é muito clara, é melhor ler algumas informações sobre o RED no site da Juniper / Cisco e aplicar esse conhecimento ao tc.

Como é calculada a taxa de 256K bits / s? Neste exemplo, 32.000 bps = [32.000] bytes por segundo.

Sim, a matemática está correta. Se você estiver vendo um número próximo a 256k, provavelmente está um pouco abaixo. De onde você está medindo esse número? Se for o downlaod do navegador ou algo semelhante, eles não contam a sobrecarga dos cabeçalhos de pacotes, mas tccontam tudo.

Na minha experiência, o qdisc TBF é facilmente capaz de limitar a largura de banda a 1 Gbps, então eu acho que ele também aumentará para 2 Gbps. No entanto, você provavelmente precisará de uma CPU real para o trabalho, em vez de um roteador de borda de gama baixa. Algo como 4 GHz i3 certamente será suficiente.

Tente algo como

tc qdisc add dev "$DEV" root handle 1: \
  tbf rate "$UPLINK_RATE" burst "$UPLINK_BURST" latency "$TBF_LATENCY"

Onde

DEV="$(ip route | grep "^default " | grep -Po "(?<=dev )[^ ]+")"
UPLINK_RATE="2000Mbit"
UPLINK_BURST="6500"
TBF_LATENCY="14ms"

Observe que, para usar o TBF de baixa latência, pode ser necessário executar o kernel PREEMPT (por exemplo, linux-lowlatency-hwe-*pacote Ubuntu ) ou o sistema pode falhar ao manipular todos esses pacotes.

Veja também: https://networkengineering.stackexchange.com/a/54404/36597