Usando o qdisc prio na classe htb

Question

Eu tenho 2 serviços, ambos operam na mesma interface.
Serviço Uma meta é manter alta largura de banda ao enviar uma quantidade enorme de dados.
O objetivo do serviço B é de baixa latência.

Pacotes Service B devem sempre ser a favor dos pacotes A do Service.
Eu preciso de uma estrutura de TC para poder:

• Taxa limite para o serviço A & B
• Forneça prioridade aos pacotes do serviço B com 0% de latência afetada pelos pacotes do serviço A.
• Deixe que cada serviço utilize toda a linha (ou até o limite) se o outro serviço não estiver transmitindo.

Eu tentei sobre uma estrutura htb onde eu tenho class htb classid x , que pode ser taxa / ceil limite e qdisc prio (digamos, identificador y: 0) abaixo como filho (ele deve criar automaticamente classes y: 1, y: 2 & y: 3) e usar filtros por src ip para redirecionar os pacotes para y: 1 / y: 2.
No entanto, não parece funcionar.
Ambos class x e seu tráfego filho parecem ser 0. (usado tc -s class/qdisc/filter show dev dev para ver)
Ao assistir os filtros, posso ver claramente os "hits", para que os dados sejam redirecionados corretamente.

Aqui estão os comandos que eu executo:

tc qdisc add dev dev root handle 1: htb
tc class add dev dev parent 1:0 classid 1:1 htb rate 10gbit ceil 10gbit
# class x
tc class add dev dev parent 1:1 classid 1:2 htb rate 10gbit ceil 10gbit
# auto creates classes 21:1, 21:2 and 21:3
tc qdisc add dev dev parent 1:2 handle 21: prio
# example for service b filter (latency driven)
tc filter add dev dev parent 1:0 prio 2 u32 match ip src x.x.x.x/32 flowid 21:1
# example for service a filter
tc filter add dev dev parent 1:0 prio 2 u32 match ip src x.x.x.x/32 flowid 21:2

    

Answer 1

Não faça isso há muito tempo ... tome minha resposta com um grão de sal.

O pai do filtro pode ter que ser o qdisc PRIO em si (então você tem filtros HTB e filtros PRIO, ...). Caso contrário, o PRIO pode reclassificar pacotes por si próprio de acordo com o priomap.

Isto é o que parecia em um script antigo meu (FairNAT, você pode encontrar a coisa toda no GitHub) e eu tenho certeza que costumava trabalhar na época ... pacotes não foram filtrados por IP, mas marcados por iptables neste caso (o que também vale a pena tentar se você suspeitar que o filtro ip seja desonesto).

# Create a prio qdisc with 4 classes. All P2P traffic goes into class 4.
        $BIN_TC qdisc add dev $UC_DEV parent 1:$UC_MARK handle $UC_MARK: prio \
                          bands 4

# Add a filter for IPP2P to this qdisc. The rest depends on TOS.
        $BIN_TC filter add dev $UC_DEV parent $UC_MARK: protocol ip \
                       handle $(($UC_MARK+1)) fw flowid $UC_MARK:4

PRIO não é uma boa escolha na maioria das vezes. É muito agressivo, pode matar completamente todo o tráfego.

Ter apenas uma única classe HTB também pode não ter o efeito desejado. Limitar ao 10GE também soa um pouco estranho para mim, se essa é a velocidade teórica do link que nunca é alcançada na prática, simplesmente não fará nada.

HFSC pode ser mais adequado para a tarefa. A documentação é ainda pior do que o HTB, mas é mais capaz de classificar o limite e priorizar (o HTB realmente não prioriza absolutamente nada).