Por que essa regra "tc filter" não classifica o tráfego como pretendido?

Question

Estou tentando configurar uma classificação básica de tráfego para limitar a largura de banda máxima de entrada para cada máquina na rede local a 3 Mbps. Estou operando o gateway 192.168.2.1, onde a interface eth1 está conectada a um switch para fornecer conexão de Internet para hosts em 192.168.2.0/24 .

A classificação é simples: o tráfego de ingresso é classificado como info duas classes, a primeira classe 1:20 é para o tráfego não classificado por padrão como fallback, a segunda classe 1:30 limitaria a banda de entrada a 3 Mbps. Então eu uso um tc filter para classificar o tráfego originado de cada host como classe 1:30 .

# Clear the qdisc first.
tc qdisc del root dev eth1

# Set a HTB qdisc on the root, and use class 1:20 by default
tc qdisc add dev eth1 root handle 1: htb default 20

# Create class 1:1, limit the total ingress bandwidth to 8 Mbps.
tc class add dev eth1 parent 1: classid 1:1 htb rate 8mbit burst 15k

# Class 1:20
tc class add dev eth1 parent 1:1 classid 1:20 htb rate 5mbit ceil 5.5mbit burst 15k

# Class 1:30
tc class add dev eth1 parent 1:1 classid 1:30 htb rate 3mbit ceil 4mbit burst 15k

# Attach fq_codel w/ ECN on each class to control latency / bufferbloat.
tc qdisc add dev eth1 parent 1:20 handle 20: fq_codel ecn
tc qdisc add dev eth1 parent 1:30 handle 30: fq_codel ecn

# Match the LAN range and classify them as class 1:30
tc filter add dev eth1 parent 1: protocol ip prio 2 u32 match ip src 192.168.2.0/24 flowid 1:30

No entanto, a regra não funciona conforme o esperado. A velocidade de download dos hosts ainda é a largura de banda mais alta especificada em 1:20 , não 1:30 . Qual é o meu erro?

    

Answer 1

Qual é a sua versão do kernel?

Eu estou tentando configurar algo similar, e estou tendo a strong impressão de que o kernel debian 4.15.0-23-generic está quebrado. Problema não é com o próprio HTB, mas com a classificação de pacotes para corrigir o fluxo de classid.

Até mesmo este exemplo educacional falha:

tc qdisc add dev int0 root handle 1:0 htb r2q 100000 default 13
tc class add dev int0 parent 1:0 classid 1:1 htb rate 10Gbit
tc class add dev int0 parent 1:1 classid 1:11 htb rate 1Gbit ceil 2Gbit
tc class add dev int0 parent 1:1 classid 1:12 htb rate 1Gbit ceil 2Gbit
tc class add dev int0 parent 1:1 classid 1:13 htb rate 1Gbit ceil 2Gbit

quando

tc -s -d filter show dev int0

Você vê que todos os pacotes passam corretamente por 1:13

mas se você fizer

iptables -t mangle -A POSTROUTING -j MARK --set-mark 11
tc filter add dev int0 parent 1:0 protocol ip handle 11 fw flowid 1:12

funciona de forma estranha, apenas alguns pacotes a cada poucos minutos vão como esperado, outros ainda passam pelo padrão

próximo exemplo de tentativa de classificação:

ipset create SHAPER4 hash:net family inet skbinfo
ipset add SHAPER4 10.0.0.0/8 skbprio 1:12
iptables -t mangle -A POSTROUTING -j SET --map-set SHAPER4 src,dst --map-prio

funciona da mesma forma (parece que, estatisticamente, mais pacotes acertam do que no exemplo anterior)

Não há erros ou avisos nos logs, apenas trabalhe assim

tc -s -d class show dev int0

class htb 1:13 parent 1:1 prio 0 quantum 1250 rate 1Gbit ceil 10Gbit 
linklayer ethernet burst 1375b/1 mpu 0b overhead 0b cburst 0b/1 mpu 0b 
overhead 0b level 0
 Sent 74139067325 bytes 53655936 pkt (dropped 0, overlimits 48986938 requeues 0)
backlog 0b 0p requeues 0
lended: 41808373 borrowed: 11847563 giants: 0
tokens: -81 ctokens: -4

class htb 1:11 parent 1:1 prio 0 quantum 1000 rate 10Mbit ceil 100Mbit 
linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 0
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
lended:  borrowed: 0 giants: 0
tokens: 20000 ctokens: 20000

class htb 1:12 parent 1:1 prio 0 quantum 1000 rate 5Mbit ceil 30Mbit 
linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1593b/1 mpu 0b 
overhead 0b level 0
Sent 4704 bytes 48 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
lended: 48 borrowed: 0 giants: 0
tokens: 37550 ctokens: 6247

Algum desenvolvedor de redes de kernel aqui?

Vou tentar outras versões antes de denunciá-lo :)

    

Answer 2

tc está operando no upload. Então, se você quer moldar o tráfego de entrada, você tem que colocar as regras na interface lan.

Supondo que você está fazendo isso, sua regra deve corresponder ao destino 192.168.2.0/24, e não origem.