Mecanismos de QoS em Linux Hierarchical Token Bucket (HTB) Este roteiro descreve um cenário prático onde o algoritmo Hierarchical Token Bucket (HTB) é utilizado para criar uma política de QoS flexível, que suporta ao mesmo tempo garantias de banda e evita a subutilização de recursos através de mecanismos de empréstimo. O aluno deverá executar esse roteiro e enviar através do Eureka o relatório em formato texto, descrito na última página dessa apostila.
(apresentação da política) eth0 qdisc 1:0 HTB root eth1 qdisc 2:0 HTB root UPLOAD class 1:1 HTB rate 128kbps DOWNLOAD class 2:1 HTB rate 256kbps class 1:2 HTB rate 96kbps ceil 128kbps class 1:3 HTB rate 32kbps ceil 128kbps class 2:2 HTB rate 192kbps ceil 256kbps class 2:3 HTB rate 64kbps ceil 256kbps qdisc 10:0 FIFO qdisc 20:0 FIFO qdisc 30:0 FIFO qdisc 40:0 FIFO TCP outros host A host B Nesta prática, será implementado a política ilustrada pela figura. Uma empresa possui um link com a Internet com capacidade de 256kbps para download e 128kbps para upload (no tc, kpbs significa "kbytes por segundo" e kbit significa "kbits por segundo"). O objetivo da política de QoS é controlar como os recursos do link serão utilizados pelos dois computadores, mas impondo taxas diferentes: a) O computador A pode fazer download a uma taxa garantida de 192Kbps, atingindo 256kbps caso o computador B não esteja transmitindo simultaneamente. b) O computador B pode fazer download a uma taxa garantida de 96Kbps, atingindo 256kbps caso o computador A não esteja transmitindo simultaneamente. c) Ambos os computadores podem fazer upload de tráfego TCP a uma taxa garantida de 96kbps, compartilhada entre eles. Caso não haja outros tipos de tráfego ocupando o link, o upload de tráfego TCP poderá ser feito até 128kbps. d) Ambos os computadores podem fazer upload de outros tipos de tráfego a uma taxa garantida de 32kbps, compartilhada entre eles. Caso não haja tráfego TCP ocupando o link, o upload de outros tipos de tráfego poderá ser feito até 128kbps. Nessa prática, serão criadas três máquinas virtuais: host A, host B e roteador G. O servidor espec fará o papel de recursos disponíveis na Internet. Para que o roteamento entre os hots A e B e a espec funcione, é necessário criar uma política de NAT (SNAT) no roteador G. Dessa forma, o roteador G terá dois tipos de configuração: a) Uma regra de SNAT para permitir o acesso dos computadores A e B com a Internet b) Uma política de QoS implementada com o comando tc para controlar a banda usada pelos hosts Praticamente todas as configurações importantes dessa prática são realizadas no roteador G. É necessário instalar apenas o pacote de iptables no roteador G para ter acesso as funções de NAT, uma vez que os recursos de QoS utilizados estão disponíveis ao nível do kernel.
(Passos 1 a 3: configuração da rede) 10.13.14.3 (eth1) B rede 1 (eth1) 10.13.14.1 (eth1) G espec 20.0.0.1 A 10.13.14.2 (eth1) 20.13.14.1 (eth0) 256kbps 128Kbps Internet REDE DA EMPRESA: 10.13.14.0/24 1) Preparação do roteador G: Todos os exemplos a seguir supõe que seu código de estudante é (101) 11 12 13 14 X. Tome cuidado para troca as ocorrências X.13.14.X pelo seu próprio código. 1a) Na ESPEC: Crie uma pasta no seu diretório e inicialize uma VM com o nome G. > mkdir qos > cd qos > linux32.redes G 1b) Em G: Atribua os endereços IP, habilite o roteamento e crie a política de NAT. > ifconfig eth0 20.13.14.1/8 > ifconfig eth1 10.13.14.1/24 > sysctl net.ipv4.ip_forward=1 > wget 20.0.0.1/~jamhour/pacotes/iptables.tar.gz > tar xzf iptables<tab> > cd iptables > rpm ivh iptables<tab> > iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 20.13.14.1 2) Preparação do host A: 2a) Na ESPEC: Na mesma pasta que você criou G, inicialize uma máquina virtual com o nome A. > linux32.redes A 2b) Em A: Atribua o endereço IP e crie a rota default para o host. > ifconfig eth1 10.13.14.2/24 > route add default gw 10.13.14.1 3) Preparação do host B: 3a) Na ESPEC: Na mesma pasta que você criou G, inicialize uma máquina virtual com o nome B. > linux32.redes B 3b) Em B: Atribua o endereço IP e crie a rota default para o host. > ifconfig eth1 10.13.14.3/24 > route add default gw 10.13.14.1
(Passo 4: criação da política de QoS) #!/bin/bash # POLITICA DE UPLOAD (eth0) tc qdisc del dev eth0 root tc qdisc add dev eth0 handle 1:0 root htb tc class add dev eth0 parent 1:0 classid 1:1 htb rate 128kbps tc class add dev eth0 parent 1:1 classid 1:2 htb rate 96kbps ceil 128kbps tc class add dev eth0 parent 1:1 classid 1:3 htb rate 32kbps ceil 128kbps tc qdisc add dev eth0 parent 1:2 handle 10:0 pfifo limit 10 tc qdisc add dev eth0 parent 1:3 handle 20:0 pfifo limit 10 tc add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip protocol 0x06 0xff flowid 1:2 tc add dev eth0 parent 1:0 protocol ip prio 2 u32 match ip protocol 0x00 0x00 flowid 1:3 # POLITICA DE DOWNLOAD (eth1) tc qdisc del dev eth1 root tc qdisc add dev eth1 handle 2:0 root htb tc class add dev eth1 parent 2:0 classid 2:1 htb rate 256kbps ATENÇÃO tc class add dev eth1 parent 2:1 classid 2:2 htb rate 192kbps ceil 256kbps tc class add dev eth1 parent 2:1 classid 2:3 htb rate 64kbps ceil 256kbps tc qdisc add dev eth1 parent 2:2 handle 30:0 pfifo limit 10 tc qdisc add dev eth1 parent 2:3 handle 40:0 pfifo limit 10 tc add dev eth1 parent 2:0 protocol ip u32 match ip dst 10.13.14.2/32 flowid 2:2 tc add dev eth1 parent 2:0 protocol ip u32 match ip dst 10.13.14.3/32 flowid 2:3 4) Criação das políticas de QoS em G: Observe que a interface eth0 do roteador controla o tráfego de upload feito pelos hosts, e a interface eth1 controla o tráfego de download. Dessa forma, é necessário criar uma política independente para cada uma das interfaces. O número de handle de políticas associadas a interfaces diferentes são independentes, e podem ser duplicados. Isto é, poderíamos ter criado uma classe root com o handle 1:0 para as interfaces eth0 e eth1 sem confusão. Contudo, no exemplo, números diferentes foram usados para evitar confusão e facilitar o acompanhamento de estatísticas usando com comando tc qdisc show. Os scripts para criação da política de QoS para as duas interfaces estão ilustrados na figura. O primeiro comando do script limpa configurações anteriores. Por isso, não estranhe ao receber uma mensagem de no such file or directory quando executar o script pela primeira vez. Os scripts são muito semelhantes, as diferenças entre eles apontadas em vermelho na figura. É importante destacar que em um cenário com NAT não é possível distinguir os endereços IP dos pacotes enviados para Internet, pois eles contém sempre o IP do roteador. Dessa maneira, a política de UPLOAD é baseada no tipo do protocolo e não no ip dos hosts. Observe que na política de DOWNLOAD os endereços dos hosts são usados como destino. A criação do script não é obrigatória, pois é possível digitar os comandos individualmente no prompt da máquina virtual. Contudo, como os comandos são acumulativos, o script é mais indicado pois ele sempre apaga qualquer elemento de QoS que já exista antes de executar os comandos da nova política. 4a) Na VM G: Utilizando o vi, crie o script conforme indicado na figura. Observe que o parâmetro -x na primeira linha do script fará com todos os comandos sejam impressos no seu terminal com o respectivo erro (se houver). Dessa forma, é fácil localizar qual foi a linha que causou problema. > vi htb.sh... <INS> digitar o script <ESC>:wq > chmod +x htb.sh >./htb.sh
(Passo 5: Teste de DOWNLOAD) 10.13.14.3 (eth1) B wget www.dns.tar.gz rede 1 (eth1) 10.13.14.1 (eth1) G espec 20.0.0.1 A 10.13.14.2 (eth1) 20.13.14.1 (eth0) 256 Kbps Internet 5) Avaliação da velocidade de download em A e B 5.a) Na VM A: Efetue o download de um arquivo a partir da espec e anote a velocidade média obtida. > wget 20.0.0.1/~jamhour/pacotes/dns.tar.gz 5.b) Na VM B: Repita o procedimento descrito no passo 5.a para a VMB. > wget 20.0.0.1/~jamhour/pacotes/dns.tar.gz 5.c) Em VM A e VMB: Execute o download simultaneamente nas duas VMs, e anote a velocidade média obtida para cada uma das VMs. O objetivo desse teste é verificar o comportamento da política quando ambas as classes são usadas simultaneamente. Não haverá muita precisão nesse teste, pois assim que o download de uma das VMs encerrar, a taxa da outra irá aumenta. Anote simplesmente a taxa mostrada pelo wget ao final do download. > wget 20.0.0.1/~jamhour/pacotes/dns.tar.gz 5.d) Em G: Verifique e salve as estatísticas coletadas no roteador. > tc -s class show dev eth1 > download.txt Verifique se as políticas das classes foram criadas corretamente (você verá três classes, uma representando a taxa total de download, e outras duas, representado as taxas dos hosts A e B). Observe que taxa das classes em kbits, por isso ela deve ser igual ao valor da sua política*8. Veja a quantidade de pacotes e o que ocorreu em cada uma das classes da sua política de upload.
(Passo 6: Teste de UPLOAD) 10.13.14.3 (eth1) B scp www.dns.tar.gz rede 1 (eth1) 10.13.14.1 (eth1) G espec 20.0.0.1 A 10.13.14.2 (eth1) 20.13.14.1 (eth0) 128 Kbps Internet 6) Avaliação da velocidade de upload em A e B 6.a) Na VM A: Efetue o upload de um arquivo da VM para espec e anote a velocidade média obtida, pois ela será usado no relatório. > scp dns.tar.gz seu_login@20.0.0.1:. 6.b) Na VM B: Repita o procedimento descrito no passo 6.a para a VMB. > scp dns.tar.gz seu_login@20.0.0.1:. 6.c) Em VM A e VMB: Execute o upload simultaneamente nas duas VMs, e anote a velocidade média obtida para cada uma das VMs. O objetivo desse teste é verificar o comportamento da política quando ambas as classes são usadas simultaneamente. Não haverá muita precisão nesse teste, pois assim que o download de uma das VMs encerrar, a taxa da outra irá aumenta. Anote simplesmente a taxa mostrada pelo wget ao final do download. > scp dns.tar.gz seu_login@20.0.0.1:. 6.d) Em G: Verifique e salve as estatísticas coletadas no roteador. > tc -s class show dev eth0 > upload.txt Verifique se as políticas das classes foram criadas corretamente (você verá três classes, uma representando a taxa total de upload, e outras duas, representado as taxas do TCP e outros). Observe que taxa das classes em kbits, por isso ela deve ser igual ao valor da sua política*8. Veja a quantidade de pacotes e o que ocorreu em cada uma das classes da sua política de upload.
Relatório da Prática Crie um arquivo denominado RelatorioPraticaQoSHTB.txt com as seguintes informações: A) Velocidade média de download de A e B sozinhos. B) Velocidade média de download de A e B simultâneos. C) Velocidade média upload obtida de A e B sozinhos. D) Velocidade média upload obtida de A e B simultâneos. Crie um arquivo denominado RelatorioPraticaQoSPRIOTBF.txt com as seguintes informações: A) Velocidade média de download de A e B sozinhos. Você deve ter obtidos esses dados respectivamente nos passos 5a e 5b desta prática. B) Velocidade média de download de A e B simultâneos. Você deve ter obtidos esses dados respectivamente no passo 5c desta prática. C) Velocidade média de upload de A e B sozinhos. Você deve ter obtidos esses dados respectivamente nos passos 6a e 6b desta prática. D) Velocidade média de upload de A e B simultâneos. Você deve ter obtidos esses dados respectivamente no passo 6c desta prática.