Aplicação de QoS por meio de Classes de Serviços com HTB e IPTABLES

Transcrição

1 ISSN T.I.S. São Carlos, v. 1, n. 3, p , jan-abr Tecnologias, Infraestrutura e Software Aplicação de QoS por meio de Classes de Serviços com HTB e IPTABLES Flávio Oliveira, Jander Moreira Resumo: O controle e a priorização do tráfego em uma rede é atualmente um método de gerenciamento indispensável para administradores de rede. Com a constante disponibilização de informações através da internet, seja no formato de textos, imagens ou vídeos e atualmente o acesso às redes sociais, o controle desses acessos torna-se um ponto primordial no controle das redes. Nesse cenário, a possibilidade de controlar esse acesso pela caracterização do serviço será de grande valor para um bom gerenciamento de uma rede de computadores. Neste trabalho, essa forma de controle será tratada através do uso das ferramentas implementadas em computador que tem o papel de roteador em uma rede configurado com GNU/Linux. O uso do iptables existente no kernel Linux, para marcação dos pacotes que transitam na rede em conjunto com a ferramenta de controle de tráfego TC e do algoritmo HTB para criação de classes para identificar e controlar esse tráfego será apresentado.. Palavras Chave: QoS, HTB, IPTABLES, Controle de Tráfego QoS application through service classes with HTB and IPTABLES Abstract: The control and prioritization oftraffic on a network are currently indispensable management methods for network administrators. With the constant availability of information via the Internet, whether in the form of texts, images or videos and now by accessing social networks, such access control becomes an essential point in controlling networks. In this scenario, the ability to control this access by the characterization of the service will be of great value for a good management of a computer network. In this work, this form of control is handled through the use oftools implemented in the computer working as the router in a network configured with GNU / Linux. The use ofthe existing Linux kernel iptables to tag the packets that pass through network together with a traffic control tool TC and HTB algorithm for creating classes to identify and control this traffic will be presented. Keywords: QoS, HTB, IPTABLES, Traffic Control I. INTRODUÇÃO Novos serviços e informações são disponibilizados para uso através do acesso à internet e, com isso, a quantidade de conexões cresce significativamente ano após ano. Em contrapartida, ferramentas são utilizadas para se tentar controlar o uso desses recursos. Administradores, analistas e técnicos responsáveis pela administração de redes conectadas em todas as regiões utilizam ferramentas para controlar os acessos de usuários internos às suas redes e aos conteúdos existentes. Uma forma utilizada para o controle de acesso é através da aplicação do conceito de QoS (Quality of Service). Segundo STATO FILHO (2009), com QoS torna-se possível a definição de ordem de precedência no tráfego existente, priorizando o acesso com mais relevância e, assim, disciplinar o acesso aos recursos da Internet, visando os interesses da empresa ou instituição. Com o uso do QoS, espera-se um melhor controle em fatores como atrasos nas conexões que venham a ocasionar perda de informações. Essa situação gera custos desnecessários para empresas e instituições, tanto em consumo de banda com em tempo de profissionais envolvidos na administração da rede. Porém, com o continuo aumento no acesso aos recursos da Internet, torna-se necessário também a existência de classificação dos serviços a serem acessados, a fim de se aprimorar esse controle. Segundo TANENBAUM (2003), a IETF (Internet Engineering Task Force), propos um conjunto de alterações no campo TOS contido na estrutura do cabeçalho do protocolo IPv4, a fim de poder oferecer a opção de qualidade de serviço. Essas alterações foram padronizadas com o nome de arquitetura de serviços diferenciadas que estão descritas em RFCs como a 2474 e a Com a existência deste cenário, é indicado o uso do método DiffServ (Serviços Diferenciados) que se baseia no algoritmo de balde furado, originado a partir dessa padronização para agrupamento específico de classes de Departamento de Computação - Universidade Federal de São Carlos (UFSCar) Caixa Postal São Carlos SP Brasil Autor para correspondência: flaolsc@hotmail.com, jander@ufscar.br

2 Flávio Oliveira, Jander Moreira serviços na internet (STATO FILHO 2009). Para tal, o uso do algoritmo HTB (Hierarchical Token Bucket) para tratar essas classes é uma opção útil e indicada. Para KUROSE (201 0), algumas das vantagens no uso do método ou arquitetura Diffserv são a sua capacidade de ser flexível e escalável. A flexibilidade será fundamental no processo de inserção ou remoção de novas classes das estruturas existente. Devido ao trafego em constante crescimento, um serviço escalável, possuirá capacidade de atendimento e será imprescindível para o uso. Com a definição do algoritmo que utilizará essas classes, falta a escolha de uma ferramenta que consiga trabalhar em conjunto para marcação dos pacotes que transitam pela rede para a referida classificação. O uso da ferramenta iptables existente no kernel Linux a partir da versão 2.4 será fundamental para a devida marcação dos pacotes. O presente trabalho, baseando-se no método de QoS DiffServ, objetiva apresentar o uso das ferramentas IPTABLLES, TC (Traffic Control) e do algoritmo HTB para devida identificação dos pacotes e criação de classes de serviços para acesso à internet a fim de se controlar esse tráfego. Na seção II é descrito a alteração no campo ToS visando a implementação do método DiffServ. O uso do iptables e sua utilização na marcação de pacotes será abordada na seção III. Na seção IV é apresentado o uso da ferramenta TC em conjunto com o HTB para criação das estruturas das classes, filas e o conjunto de filtros no roteador. Uma aplicação será apresentada na seção V com uma implementação dessa solução em um ambiente virtual. Na seção VI apresenta-se uma proposta de implementação de estrutura para QoS na estrutura de rede do Departamento de Computação (DC) na Universidade Federal de São Carlos. Na seção VII é descrito um roteiro para implementação das estruturas de QoS em uma rede de dados será sugerido. Por fim, são apresentados as conclusões sobre a implementação. II. IDENTIFICAÇÃO DOS PACOTES Para o uso do HTB (DiffServ) funcione com a priorização por serviços torna-se necessário a marcação dos pacotes que estejam transitando na rede. Assim, ao chegar ao roteador da rede, os pacotes seguirão para suas respectivas filas. Segundo a RFC 2474 (Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers) a marcação dos pacotes, deve ser entendida da seguinte forma: Segundo essa RFC, diferenciação de serviços é um aprimoramento para o protocolo de IP que tem como finalidade permitir o reconhecimento de serviços escaláveis na Internet sem a necessidade de especificar o estado de sinalização em cada nó da rede. A classificação de serviços pode ser construída a partir de um pequeno conjunto bem definido de blocos de construção que são implantados em nós da rede. Os serviços que trabalharão entre domínio, incluem tanto os que podem satisfazer os requisitos de desempenho quantitativo (por exemplo, o pico ou a largura de banda) ou os baseados no desempenho relativo (por exemplo, classe de diferenciação). Esses serviços podem ser construídos por uma combinação de: 1. Pedaços de configuração em um campo que está contido no cabeçalho IP da rede local, 2. Usar bits descritos no campo marcado para determinar como os pacotes serão encaminhados, 3. Condicionando os pacotes marcados na rede local, em conformidade com os requisitos e normas de cada serviço. (RFC 2474) A alteração na estrutura do campo ToS que faz parte do conjunto de informações contidos no cabeçalho IPv4 pela IETF que foram padronizadas pelas RFCs 2474, 2475 (TANENBAUM, 2003) a fim de implementar o suporte ao método de serviços diferenciados (DiffServ) deixou a mesma como descrito na figura 1. Figura 1. Estrutura do cabeçalho IPv4 A figura 1 mostra como acontece essa alteração, o campo ToS recebeu modificações e passou a conter duas áreas especificas, o DSCP (DiffServ Code Point) contendo seis bits e o CU ou NU (Currently Unused) com dois bits que não será utilizado para classificação dos pacotes. A partir dessa implementação, tornou-se possível todo o controle por classes de serviços separando-se em filas especificas no roteador da rede. Nesse campo DSCP estará associado o PHB (Per Hop Behavior) que será o identificador de cada classe existente. O conjunto agregado de pacotes com mesmas características e comportamentos será denominado de BA (Behavior Aggregate) (STATO FILHO, 2009). No cabeçalho IPv6, o campo a ser utilizado para identificação será o Traffic Class (TC) para o método DiffServ, possuindo oito bits e o Flow Label (identificador de fluxo) com conteúdo de 20 bits. Esse campo fornecerá as mesmas possibilidades que o ToS existente no IPv4 que já foi anteriormente demonstrado. Um ponto importante a ser ressaltado é que o uso adequado do método DiffServ requer a configuração dos equipamentos (roteadores) envolvidos no tráfego pois somente pela existência desse método em uma determinada área não poderá T.I.S. 2014; 3 (1 ):

3 Controle de tráfego através de classes com Iptables e HTB ser garantido que exista QoS na conexão. Dessa forma, roteadores que fazem parte de uma estrutura de rede de uma instituição, empresa ou provedor de serviços de internet, por exemplo, conseguirão entender as classificações e poderão oferecer suporte a Qualidade de Serviço dentro dessa área após a definição das classes de serviços com suas respectivas normas de encaminhamento (TANEMBAUM, 2003). III. MARCAÇÃO DE PACOTES UTILIZANDO O IPTABLES Como o foco desse trabalho é implementação de QoS dentro de um ambiente com o GNU/Linux funcionando, definiu-se como uma boa opção de ferramenta para a marcação dos pacotes o iptables que faz parte do módulo NETFILTER. Existente desde a versão 2.4 do kernel Linux, através do módulo ip_tables, o iptables proporciona ferramentas para devida marcação de pacotes a partir do uso de um conjunto de regras existentes. De forma simples, o iptables é um conjunto de 4 tabelas vazias, filter, nat, raw e mangle que a partir da criação de regras de controle de tráfego utilizando elementos classificadores ou de ações especificas, possibilita controle do fluxo por parte do administrador do sistema. Dentre as características do conjunto netfilter e iptables, a que será abordada nesse trabalho é a capacidade de manipulação de dados do cabeçalho IPv4 (TOS/DSCP) existentes nos pacotes que trafegam na rede a fim de trabalhar em conjunto com o TC (Traffic Control) para criação de politicas que visam à implementação de QoS na rede. Atualmente, o iptables tem suporte para as duas versões do protocolo IP ativas, a versão IPv4 e a IPv6 a partir da utilização dos aplicativos iptables e do ip6tables. No trabalho, com função de roteador, foi usada uma máquina virtual configurada com uma versão do GNU/Linux, a Debian Squeeze (versão 6). O tratamento dos pacotes se dará diretamente no kernel e permitirá que decisões sejam tomadas referentes ao bloqueio, redirecionamento, geração de logs das comunicações por exemplo. Após a definição das regras que serão criadas, o administrador do sistema com essa estrutura pronta, utilizará a ferramenta iptables para essa interação. A figura 2 demonstra como é o fluxo dos pacotes nesse roteador. Os três retângulos marcados na figura 2 são as indicações de listas com regras pertencentes à estrutura da tabela filter, as CHAINS. Quando um pacote chega nessa estrutura, iniciase a análise para saber se será aceito (ACCEPT) ou rejeitado (DROP). O kernel analisará o pacote para verificar se ele tem como destino a máquina local ou se deverá ser repassado (FORWARD) para outro dispositivo de rede caso exista suporte a essa operação. Sendo o destino à máquina local, o pacote seguirá para a lista de regras input e será analisado de acordo com as regras existentes. Não sendo compatível com nenhuma regra definida, o kernel ira verificar como está definida a regra padrão da chain input para identificar se deve aceitar ou rejeitar o pacote. Para que o FORWARD tenha suporte, é recomendada a verificação do parâmetro net.ipv4.ip_forward no kernel. Esse parâmetro deve estar com o valor igual a 1. Das tabelas existentes, será na tabela mangle que os pacotes poderão receber códigos ou informações em seus cabeçalhos IP, tanto no IPv4, quanto no IPv6 e essas modificações nos conteúdos dos campos poderão ser usadas por exemplo na identificação para posterior controle nas filas de saída do roteador. Com isso, informações sobre o uso da tabela mangle para que seja efetuada mudança nos dados dos pacotes serão apresentadas. A figura três mostra a disposição das estruturas da tabela mangle dentro das rotinas de roteamento presentes no kernel. Figura 3. Trânsito de pacotes pelas tabelas do iptables (adaptada do site Figura 2. Trânsito de pacotes pelos filtros do iptables (adaptada do site Nota-se na figura 3 que a mangle possui as chains prerouting, input, forward, output e postrouting. A disposição das localizações da chains da mangle na figura três não está de forma aleatória. O fluxo de pacotes passa inicialmente pelas tabelas da mangle para se definir se há necessidade de modificações de acordo com as políticas existentes de QoS. Nas tabelas filter e nat, o processo de análise de pacote é 60 T.I.S. 2014; 3 (1 ): 58-68

4 Flávio Oliveira, Jander Moreira sequencial com final estabelecido no momento que o pacote tem correspondência com alguma regra existente. No caso da mangle, a leitura é feita sequencialmente, porém, até o fim das regras. Entre os alvos de marcações que pode ser usados com as regras da mangle estão TOS, MARK, CLASSIFY, DSCP, TTL, TCPMSS entre outros. Para o desenvolvimento do trabalho em questão, serão demonstrados alvos com maior relevância. A) TOS Usa-se o TOS para alterar as informações que estão no campo tipo de serviço que faz parte do cabeçalho IP. Assim, é possível criar privilégios dentro de uma política de regras estabelecidas em uma rede. A tabela 1 apresenta os valores que definem a escala de prioridades. Tabela 1. Escala de prioridades Define-se que o código para maior prioridade como o 0x1 0 ou 1 6 e para menor prioridade o 0x00 que é o código padrão sem alterações no pacote. Para uso do ToS, deve-se utilizar o complemento de marcação set-tos. O uso fica da seguinte forma: iptables t mangle -A ( CHAI N) -j TOS set-tos prioridade Para verificar as regras existentes, o comando usado é o seguinte: iptables -t mangle -L Como exemplo do uso, priorização de trafego HTTP e SSH na saída da rede: iptables -t mangle -a OUTPUT -o eth0 -p tcp dport 8 0 -j TOS set-tos 1 6 iptables -t mangle -a OUTPUT -o eth0 -p tcp dport 2 2 -j TOS set-tos 1 6 Os dois comandos citados estão colocando a saída dos tráfegos com destino a porta 80 e a porta 22 com alta prioridade, isto é, com espera mínima para o envio. Na tabela mangle será feita essa marcação e o parâmetro set-tos informa qual valor será atribuído aos pacotes. B) MARK O uso do MARK é indicado para tratamento do pacote de acordo com as regras de QoS existentes na rede. Com isso, torna-se uma ferramenta útil para uso com as filas existentes no roteador. O código indicado na marcação será reconhecido quando o pacote chegar ao roteador par ser encaminhado para sua respectiva fila de serviço. O uso do MARK com o atributo --set-mark será exemplificado como acima, para marcação de pacote HTTP e SSH. Observe os próximos dois exemplos: iptables -t mangle -A FORWARD -s / 2 4 -p tcp -dport 8 0 -j MARK set-mark iptables -t mangle -A FORWARD -s / 2 4 -p tcp -dport 2 2 -j MARK set-mark Com o ipv6, o comando é semelhante: ip6tables -t mangle -A POSTROUTI NG -p tcp dport 8 0 -j MARK set-mark Os dois comando acima que estão usando o iptables estão marcando os pacotes com origem da rede /24 que tenham como destino as portas 80 e 22 com os códigos 11 0 e 111 durante o processo de encaminhamento no roteador. O comando que usa o ip6tables para ipv6 está marcando o tráfego na estrutura de saída da tabela mangle com destino a porta 80 com código C) CLASSIFY Segundo STATO FILHO (2009), o uso do CLASSIFY pode ser indicado para configuração de um valor de prioridade e com essa classificação utilizar dentro de uma classe de serviços que usa algoritmos como o HTB que tem suporte a diferenciação de serviços e será abordado posteriormente. Esse pacote, devidamente identificado será encaminhado diretamente para sua classe correspondente. Neste trabalho foi utilizado o algoritmo HTB e descrito seu uso. A utilização do CLASSIFY será com o atributo set-class. A configuração para marcação de pacotes HTTP e SSH e consequente direcionamento sem utilização de filtros extras, como nos exemplos anteriores será da seguinte forma: iptables -t mangle -A FORWARD -s / 2 4 -p tcp -dport 8 0 -j CLASSI FY set-class 1 : 1 1 iptables -t mangle -A FORWARD -s / 2 4 -p tcp -j -dport 2 2 CLASSI FY set-class 1 : 1 2 Os comandos acima, através do uso do alvo classify, estão classificando todos os pacotes que tem sua origem no host com destino a porta 80 e 22 com os códigos 1 :11 e 1 :1 2 IV. ESTRUTURA DO QOS, FILAS, CLASSES E ALGORITMOS. Com a utilização do iptables foi possivel identificar nos pacotes para classificação, de acordo com os serviços, quando chegam ao roteador da rede. Com esse cenário, é possível a implementação de políticas ou regras objetivando a implementação do QoS na rede. Esse QoS pode ser visto de duas maneiras diferentes, a do usuário da rede que espera qualidade suficiente para enviar e receber dados, podendo ser imagens, vídeos, textos diversos de forma satisfatória e a do T.I.S. 2014; 3 (1 ):

5 Controle de tráfego através de classes com Iptables e HTB administrador do sistema que conseguirá ferramentas para gerar essa percepção aos usuários sobre os serviços prestados Segundo STATO FILHO (2009), QoS pode auxiliar na redução da saturação do uso da banda em redes que tem seus usuários em acessos a serviços de diferentes formas. Dentre os métodos de implementação existentes, esse trabalho apresenta a implementação de QoS baseando-se no método DiffServ. Como visto anteriormente, a partir da marcação dos pacotes que transitam na rede, a diferenciação dos serviços será possível a partir da criação de regras e filtros que consigam distribuir, após a identificação, os pacotes em suas filas especificas. A figura 4 ilustra o resultado esperado com a implementação do QoS baseado na diferenciação de serviços. Cada pacote será direcionado para sua fila correspondente no roteador que já estará configurado com a largura de banda possível para o uso. Figura 4. Aplicação de QoS baseado em DiffServ Para que a diferenciação de serviços (DiffServ) funcione é necessário o uso de um algoritmo que consiga trabalhar com controle do tráfego através de identificação das classes de serviços especificadas. O algoritmo escolhido foi o HTB (Hierarchical Token Bucket) que é do tipo Classfull que tem como característica o suporte a criação de novas classes pelos responsáveis pela administração do sistema. O HTB é baseado no algoritmo de balde furado ou de fichas. Através de uma analogia, feita por TANENBAUN (2003), é possível explicar esse conceito através da saída constante de água de um balde através de uma abertura em sua parte inferior, não importando a quantidade e a velocidade de água entrando no balde. Um equipamento (host) conectado a rede está enviando pacotes e a fila que está recebendo esses pacotes de acordo com o serviço e quando estiver na sua capacidade máxima de recebimento, começara a descartar os pacotes ou transbordar como no caso do balde. Assim, os pacotes não estarão na saída da fila. Essa a saída terá sempre uma velocidade constante. Como características do HTB, destacam-se a possibilidade de reserva de banda para classes especificas e quando não está sendo utilizado, o consequente empréstimo para outras classes usarem a partir de valores informados em sua configuração. Outra característica a ser ressaltada é a flexibilidade permitida para criação de classes e sub-classes. Com isso, o agrupamento de perfis de usuários levando em conta suas semelhanças torna-se possível. Como se optou por utilizar o Linux nesse trabalho, é necessário conhecer a ferramenta que será utilizada, entender sobre a criação das filas, classificadores e os filtros de marcação. Essa ferramenta é o TC (Traffic Control). Para apresentar o uso do TC em conjunto com o algoritmo HTB, será detalhado a sua estrutura de controle, com exemplos de criação dessas estruturas. A) QUEUING DISCIPLINES (QD ou QDISC) OU SCHEDULING Filas ou escalonadores são os objetos responsáveis pelo enfileiramento e saída dos pacotes após a devida classificação e armazenamento na fila correspondente. Existem dois tipos de QD, as Classless e as Classfull, sendo o tipo Classfull o utilizado nesse trabalho devido à possibilidade de suporte a criação de múltiplas filas distintas para cada serviço a ser controlado. A criação de uma QD utilizando o HTB para ser utilizada no GNU/Linux é executada da seguinte forma: tc qdisc add dev eth0 root handle 1 : 0 htb default 2 0 O comando informa que está criando uma qdisc root, que será a raiz, no dispositivo eth0, a classe de encaminhamento utilizada como padrão caso não exista correspondência entre a identificação dos pacotes com as classes e filtros existentes será a 20. Caso o pacote não tenha nenhuma fila correspondente, será utilizada a regra com código 20. O handle 1 :0 é somente o identificador. Uma observação a ser feita, quando o HTB é o algoritmo usado para criação da QD, o parâmetro que o acompanha é o default. Para consultar as qdiscs existentes, o comando é o seguinte: tc qdisc show dev eth0 Para consultar as qdiscs ativas e conseguir estatísticas, o comando seria tc -s -d qdisc list dev eth0 B) Classes É a forma como é dividido o tráfego e como será controlado. As classes estão sempre associadas aos qdiscs existentes. Um exemplo possível seria a necessidade da existência de duas classes especificas, uma para acesso HTTP e outro para SSH. Uma classe, para informar como funcionará a placa de saída, isto é, a largura de banda possível será criada em conjunto. Será necessária pelo menos a criação de 2 classes. A estrutura de criação fica da seguinte forma utilizando o tc com htb: rate tc class add dev eth0 parent 1 : 0 classid 1 : 1 0 htb mbit tc class add dev eth0 parent 1 : 1 0 classid 1 : 1 1 htb rate 1 50 kbit ceil kbit prio 0 tc class add dev eth0 parent 1 : 1 0 classid 1 : 1 2 htb rate kbit ceil kbit prio 1 A primeira regra cria a classe 1 :1 0 quer será filha da 1 :0 e informa que a eth0 funcionará a 1 00Mbps. A segunda é a criação da classe 1 :11. Essa será filha da 1 :1 0, estará usando 62 T.I.S. 2014; 3 (1 ): 58-68

6 Flávio Oliveira, Jander Moreira htb como as demais, terá um trafego (rate) permitido e garantido até 1 50kbps e quando outras filas estiverem sem usar seus limites, poderá usar emprestado (ceil) até chegar em 200kbps. A terceira é semelhante à segunda com a diferença na banda liberada, está garantindo 1 00kbps e com empréstimo até 1 80kbps. A utilização do ceil não é obrigatória e o atributo prio igual à zero está definindo a prioridade entre as classes. Para consulta das classes, o comando é executado da seguinte forma: tc -s class show dev eth0 Consultando com estatística, o comando ficaria: tc -s -d class list dev eth0 C) Filtros Filtros são responsáveis pela análise do pacote e a partir disso, com a identificação da marcação existente, fazer a distribuição nas classes existentes. Como exemplos desses filtros, tem-se fw, prio, u32, handle, parent que podem ser usados. O fw consegue buscar por marcações executados pelo iptables enquanto o u32 irá trabalhar na procura informações dentro de qualquer área do cabeçalho. Por exemplo, consegue informar que pacotes que coincidam com certo padrão Z sejam direcionados para a classe Z também. Para criação dos filtros a partir das classes superiores criadas, a estrutura do comando utilizando fw, ficaria da seguinte forma: tc filter add dev eth0 parent 1 : 0 protocol ip handle fw classid 1 : 1 1 tc filter add dev eth0 parent 1 : 0 protocol ip handle fw classid 1 : 1 2 Os comandos acima estão criando estruturas de filtros. A opção handle irá determinar o que será procurado no pacote, já a opção fw informará para qual classe o pacote terá que ser enviado. O primeiro está fazendo a ligação com a regra 1 :11 e a segunda com a 1 :1 2 que tiveram suas classes criadas anteriormente. Ambas as regras estão sendo configuradas para a interface eth0 e essa análise será feita dentro do cabeçalho ip. Utilizando o classificador u32, a estrutura seria: tc filter add dev eth0 parent 1 : 0 protocol ip u32 match ip src / 1 6 flowid1 : 1 1 tc filter add dev eth0 parent 1 : 0 protocol ip u32 match ip dport xffff flowid 1 : 1 2 A regra de inicio está colocando uma marcação 1 :11 para pacotes com origem na rede /1 6. Está regra está sendo adicionada na interface eth0 e a busca do ip de origem será feita no cabeçalho ip do pacote. A regra a seguir informa que será colocada uma marcação 1 :1 2 em pacotes que tem como destino a porta 80. Também para ipv6, o comando é similar: tc filter add dev eth0 parent 1 : 0 protocol ipv6 handle fw classid 1 : 1 1 tc filter add dev eth0 parent 1 : 0 protocol ipv6 u32 match ip6 dport xffff flowid 1 : 1 2 Para consultar as classes criadas, o comando seria executado da seguinte forma: tc filter show dev eth0 Consultando com estatística, o comando ficaria: tc -s -d filter list dev eth0 D) Policing Policing ou policers é o componente ou mecanismo que é usado para evitar que o tráfego de uma classe ultrapasse ou exceda os limites definidos. De acordo com a politica estabelecida, será possível o descarte de pacotes ou marcação dos mesmos com informe de congestionamento. V. EXPERIMENTO DE LIMITAÇÃO DE TRÁFEGO Para demonstrar o uso dessa aplicação, em um ambiente virtualizado foi configurada uma estrutura originada a partir de um cenário com classes distintas de uso e requisitos também distintos. Normalmente, em um ambiente como de uma empresa, um departamento ou instituto de ensino e pesquisa, são identificados diferentes tipos de perfis de usuários que compartilham os recursos para acesso à Internet. Com isso, após o entendimento e a devida caracterização desse ambiente, é possível a definição de grupos que utilizam e possuem o mesmo perfil. Com a referida caracterização entendida, com as necessidades e possíveis prioridades de uso determinadas, será possível a criação de classes específicas para controle e limitação do uso de determinados serviços que usam o link existente de acesso à internet para determinado fim. Com a criação das classes determinadas, a próxima etapa será a definição da quantidade de recursos que serão disponibilizados para essas classes. Com a definição executada, o próximo passo será a divisão interna dos recursos existentes de cada classe aos serviços que serão tratados e controlados pelas regras de QoS implementadas. Com todos os dados disponíveis, será possível a construção e apresentação de uma figura de fácil entendimento que auxiliará na compreensão sobre a estrutura das classes e serviços. A figura 5 apresenta a estrutura de classes criada. Figura 5. Estrutura da implementação do QoS T.I.S. 2014; 3 (1 ):

7 Controle de tráfego através de classes com Iptables e HTB Observe que a partir da figura 5 é possível identificar a existência de duas classes, 1 :1 0 e 1 :20 que foram criadas inicialmente. Devido ao perfil diferente de possíveis usuários que poderão acessar a estrutura interna da rede, essa separação em duas classes foi definida. Tais classes poderiam ser caracterizadas, por exemplo, como usuários comuns e de gerência em uma empresa ou alunos e docentes em instituição de ensino. Nessas duas classes, dois serviços foram escolhidos para terem controle de acesso ao link existente devido ao volume de tráfego. Tanto acesso HTTP, quanto SSH serão controlados com taxas diferentes para download.com essa separação em classes e o uso do iptables para marcação dos pacotes de acordo com a classe que pertençam, em um mesmo momento, dois clientes que estão fazendo um download através do HTTP por exemplo, conseguirão receber os dados com diferentes taxas de download limitadas pela taxa máxima permitida pelo serviço em cada classe. O cenário em que essa aplicação foi construída apresenta, um link máximo para download possível de 20Mbps (ou 2,5MBps por segundo) sem controle. A máquina virtual (VM) configurada para ser usada como roteador da rede possui o GNU/Linux Debian na sua versão 6. A configuração de rede dessas VM foi feita com a presença de dois adaptadores de rede da seguinte forma: eth0 ip mascara gateway eth1 ip mascara As VMs após análise do osm clientes usadas nos testes possuíam os seguintes endereços de rede em suas configurações: Cliente Cliente Cliente Cliente Todas as VMs clientes estão dentro de uma faixa de endereçamento classe C, utilizando a rede (RFC ) privada. Para efeito administrativo, de separação lógica entre clientes da classe 1 :1 0 e da 1 :20, estabeleceu-se que dentro da faixa de endereços classe C usado, endereços de até 1 27, farão parte da classe 1 :1 0 e os demais, da 1 :20. Para que as VMs cliente conseguissem acessar a internet, as seguintes instruções foram executadas na VM que tem o papel de roteador com Debian 6 para o compartilhamento de uso: echo 1 > / proc/ sys/ net/ ipv4 / ip_forward iptables -t nat -A POSTROUTING s /24 -o eth0 -j MASQUERADE Com o acesso compartilhado e sem controle de uso, a Tabela 2 mostra por VM cliente, as taxas de download que um usuário comum conseguiria via dois serviços, o HTTP através de um navegador e o SSH utilizando um cliente de transferência para SSH. A partir desses dados, será possível a verificação do resultado do controle após a implementação das regras de QoS definidas anteriormente. Tabela 2. Taxas de transferência sem aplicação QoS Ressalta-se que no momento dessas avaliações, não existiam aplicativos executando download ou upload significativo no ambiente. A execução de teste de desempenho de ultima milha através do site Simet Sistema de Medição de Tráfego Internet ( do NIC.BR nas máquinas virtuais apresentava uma taxa média para download de 1 8,07Mbps e 4,07Mbps para upload. Para criação da estrutura de controle no GNU/Linux, usouse o aplicativo TC (traffic control) e o algoritmo usado que tem suporte ao trabalho com multiplas classes é o HTB como foi mencionado anteriormente. As marcações dos pacotes que trafegam na rede e se enquadram nas politicas definidas serão executadas pelo iptables, também mencionado anteriormente. Dentro das duas classes, existem dois serviços a serem identificados, com isso, os pacotes poderiam receber quatro classificações possíveis, dentro da classe 1 :1 0 a identificação para HTTP seria 1 :11 e para SSH 1 :1 2. Para a classe 1 :20, HTTP receberia 1 :21 e SSH 1 :22. Ressalta-se que essa marcação é feita tanto no fluxo que sai quanto o que entra na rede. Com o iptables, a marcação foi executada da seguinte forma para todas as marcações, tanto download, quanto upload: iptables -t mangle -A FORWARD -p tcp --sport 8 0 -d / 2 5 -j CLASSI FY --set-class 1 : 1 1 iptables -t mangle -A FORWARD -s / 2 5 -p tcp --dport 8 0 -j CLASSI FY --set-class 1 : 1 1 A primeira estrutura implica na marcação dos pacotes com origem na porta 80 que tem como destino a faixa de endereçamento da classe 1 :1 0, de a Na segunda, a marcação está sendo executada nos pacotes com origem no range de endereçamento da classe 1 :1 0 com destino a porta 80. Com a marcação executada, os pacotes precisam ser encaminhados para as filas correspondentes as suas classes. A partir do link disponível de 20Mbps, definiu-se para aplicação, as seguintes taxas permitidas para download: Tabela 3. Limites de uso do link por classe 64 T.I.S. 2014; 3 (1 ): 58-68

8 Flávio Oliveira, Jander Moreira A Tabela 3 especifica as taxas para download permitido. Os valores no campo que informa sobre empréstimo de banda informam que, em dados momento, os recursos da rede que não estejam sendo usados em sua totalidade, podem ser usados por empréstimo até o valor informado pelas classes. Sendo necessário o uso do recurso extra por outra área da rede, a taxa retorna ao seu valor normal. Para criação da estrutura que esta representada na figura 5 com o comando tc, o HTB usado proporciona algumas opções em sua sintaxe de comando que estão brevemente descritas a seguir: rate é a taxa de uso que está garantida, a normal referenciada na Tabela 3. ceil é a taxa total, já com o possível empréstimo de banda adicional incorporado. priority é a ordem de sequência das classes. Quem tem a maior prioridade que está identificada com o valor 0, receberá em primeiro lugar o excesso (empréstimo) da banda disponível para uso naquele momento. Assim, a criação, seguindo a figura 5, inicia-se com a qdisc principal. Por essa, será feita a saída total após marcações e enfileiramentos dos pacotes. O segundo passo é a criação da classe 1 :1 que é a principal e onde será informado o valor da taxa de transmissão possível que será 20Mbps. Todas essas criações serão feitas na placa de rede que se conecta a rede local, a eth1 da VM que serve como roteador da rede e estará limitando o download. Com essa primeira ligação efetuada, é possível a criação das duas classes filhas, 1 :1 0 e 1 :20 e especificar qual taxa será destinada para uso de cada classe. A classe 1 :1 0 ficou com 1 2Mbps e para a classe 1 :20 será reservada o restante, 8Mbps. Esses valores especificarão o teto máximo de uso de cada ambiente. Com as duas classes criadas torna-se possível a criação das classes filhas internas de cada classe. Nessas classes filhas, serão estabelecidos os valores de rate e ceil para o htb como descrito anteriormente na Tabela 3. A classe 1 :1 0 receberá a 1 :11 para controle de HTTP, a 1 :1 2 para controle de SSH e a classe 1 :20 com a 1 :21 para HTTP e a 1 :22 para controle de SSH. Para adequação e controle interno, cada classe terá sua própria qdisc para que exista a ordem interna dos pacotes. Essas qdiscs utilizaram o algoritmo SFQ do tipo Classless que tem como padrão o funcionamento justo, isto é, cada classe usará a quota que foi designada em sua politica sem possibilidade de exceder a taxa máxima com eventual empréstimo de banda em momentos ociosos. A tabela 4 apresenta as taxas obtidas de transferências para os serviços HTTP e SSH nas duas classes. Também informa a porcentagem de uso por cada VM cliente. Esses valores mostram as discrepâncias em relação à tabela 2 que não possuía controle de banda ativo no momento da leitura. Tabela 4. Taxas de transferência com aplicação QoS Os valores apurados e referenciados na Tabela 4 mostram que em todos os testes, os resultados não passaram dos tetos indicados na Tabela 3 que foram anteriormente mencionados. A porcentagem indicada refere-se sobre o valor máximo possível de uso por cada classe. VI. ESTUDO DE CASO O Departamento de Computação (DC) da Universidade Federal de São Carlos (UFSCar), através de sua equipe de informática, produz registros do tráfego da rede interna dividida em 4 áreas; área docentes, área pós-graduação área graduação e área wireless. A partir desses registros, as figuras 6, 7, 8 e 9 mostram a caracterização do tráfego por área distinta. A tabela 5 apresenta o resumo de uso por protocolo em cada área. Esses dados apresentam em cada área de verificação, a porcentagem de uso por cada protocolo pelo tráfego total registrado. Figura 6. Tráfego por porta na área Docentes Figura 7. Tráfego por porta na área Pós-Graduação T.I.S. 2014; 3 (1 ):

9 Controle de tráfego através de classes com Iptables e HTB A figura 1 0 e a tabela 6 apresentam a participação das áreas dentro da amostragem de tráfego analisada. Figura 8. Tráfego por porta na área Graduação Figura 1 0. Quantidade de acesso por área analisada Tabela 6. Participação por área nos registros analisados Figura 9. Tráfego por porta na área Wireless Os registros que originaram os gráficos são referentes ao mês de setembro de Através de uma amostragem do tráfego coletado por períodos durante todas as horas do dia chegou-se a essa caracterização. Para tal, os números das portas foram identificadas com os protocolos padrões de uso, todavia, não foi aferido se algum tráfego diferente utilizou essas portas de conexão. Observa-se que nas áreas de wireless, docentes e pósgraduação, o maior tráfego e por consequência a maior necessidade é encontrada no uso das portas 80 e 443 que são as portas dos protocolos HTTP e HTTPS. A tabela 5 que é um resumo das figuras 6, 7, 8 e 9 mostra a porcentagem do uso por protocolo em cada área. A partir dos dados obtidos pelos registros analisados, é possível propor um modelo para estrutura do QoS apresentando as classes e sub-classes para os serviços existentes. Cabe ressaltar que está sendo levado em conta para o modelo, os valores obtidos através dos registros analisados. A figura 11 apresenta o modelo proposto com as classes e a participação indicada para uso. Devido a característica do algoritmos HTB, os valores podem ser alterados de acordo com a necessidade existente. Tabela 5. Composição em % do tráfego TCP das interfaces Figura 11. Estrutura da implementação do QoS no DC 66 T.I.S. 2014; 3 (1 ): 58-68

10 Flávio Oliveira, Jander Moreira Conforme ilustrado na figura 11, são criadas quatro classes, 1 :1 0, 1 :20, 1 :30 e 1 :40 que controlarão o tráfego das áreas docente, pós-graduação, graduação e wireless. De acordo com a caracterização do tráfego da tabela 6 e levando-se em conta essas proporções de uso da rede como apoio para criação da estrutura das classes, indica-se para a classe 1 :1 0 uma reserva para uso de 25% sobre a banda disponível. Para a classe 1 :20, 20%, para a 1 :30, 25% e para a 1 :40, 25%. Nesse cenário, a maior reserva para a classe 1 :40 pode ser justificada pelo uso em pesquisas dos grupos existentes, pela quantidade de usuários e pelos equipamentos em laboratórios onde são ministradas as aulas. As classe 1 :1 0, 1 :20 e 1 :30 abrigarão três sub-classes, uma para HTTP, outra HTTPS e uma chamada OUTROS que ficará com o restante do tráfego. A classe 1 :40 possuirá classes para HTTP, SSH e OUTROS. Nos gráficos 1, 2 e 4, o consumo desses dois protocolos atinge valores próximos a 85% da largura de banda possível. Com isso, dentro das sub-classes de 1 :1 0, 1 :20 e 1 :30, a reserva para HTTP e HTTPS seria respectivamente de 40% e 30% com possibilidade de empréstimo possível dentro do HTB até alcançarem 80% do uso. Os 30% restante ficariam para as outras conexões. Essa sub-classe, devido a possibilidade de empréstimo, poderia chegar a 40% em momentos de ociosidade no uso das outras sub-classes. A classe 1 :40 teria 50% de reserva para o HTTP, 20% para SSH e os 30% restante para a subclasse OUTROS. Ressalta-se que outros fatores podem influenciar em cada reserva efetuada. Prioridade em determinados momentos de serviços específicos e mudança na quantidade de usuários em cada perfil são exemplos desses fatores. Para a aplicação dessa estrutura em ambiente real, torna-se necessário um tempo para implementação na rede e consequentemente análise de comportamento. Essa interrupção das atividades em produção poderiam causar problemas e diminuição em certos períodos na produção efetiva das pesquisas. Com isso, essa proposta pode ser utilizada como base para futura implantação do QoS nas estruturas de rede do Departamento de Computação com um plano de implantação pronto e com informações disponibilizadas a todos a fim de reduzir os impactos. VII. ROTEIRO PARA IMPLEMENTAÇÃO DE UMA ESTRUTURA DE QOS Para implementação de QoS em uma rede, etapas devem ser seguidas a fim de se conseguir montar uma estrutura como apresentado na figura 11. Inicialmente, a identificação de como a rede está montada, se obedece um modelo hierárquico com segmentações ou áreas distintas presentes é fundamental. A partir disso, entendendo como funciona o fluxo de dados, será possível uma análise através da utilização de softwares em um tempo determinado, a caracterização do tráfego existente, verificando serviços acessados e volumes de dados que trafegam. Com a identificação das segmentações da rede, dos tipos de serviços acessados e volumes de dados que trafegam, a próxima etapa será a definição das classes com os serviços que serão criadas a partir de cada grupo existente. Como exemplo, os grupos podem ser determinados de acordo com os serviços identificados; outras possibilidades seriam a definição a partir das segmentações encontradas, das caracteristicas e responsabilidades dos usuários ou até mesmo das posições geográficas dentro da instituição ou empresa para se obter uma rápida localização. Segmentos conhecidos, serviços, volumes e classes estabelecidas, a estrutura pode ser desenvolvida e apresentada. Ressalta-se que devido a caracteristica do algoritmos HTB, as classes podem ser alteradas visando atender uma nova necessidade ou alteração na estrutura inicial. VII. CONCLUSÃO Este artigo apresentou aspectos relevantes ao processo de implantação de QoS por classes de serviços através do uso do algoritmo HTB e da ferramenta IPTABLES existente no Linux. A identificação dos pacotes que trafegam na rede e a consequente marcação, a criação das classes e o encaminhamento as filas correspondentes foram apresentados a fim de mostrar o processo envolvido no planejamento e implementação. Com os resultados obtidos após a aplicação das regras de controle para o QoS é possível entender que a solução de implementação de QoS em uma rede baseando-se no controle através de classes de serviços, possibilita gerenciamento eficaz do tráfego de dados na rede. Dois fatores que auxiliarão no uso dessa aplicação são a sua flexibilidade para tratar com múltiplas classes de acordo com os perfis existentes na rede e a escalabilidade para suportar um grande volume de tráfego. Com isso, a possível otimização de uso do link de internet contratada por uma empresa ou instituição de ensino será um fator importante para redução de custos e uso consciente por parte dos usuários. Na segunda aplicação, a proposta de criação de classes através das proporções de uso obtidas, mostra também a flexibilidade na criação e gerenciamento das classes. Através do uso das classes, o gerenciamento pelos administradores do uso da rede será mais preciso. A proposta de criação de um roteiro para estruturação do QoS em uma rede visa ser um apoio para o desenvolvimento de modelos em empresas e instituições. A partir da implementação do QoS por classes, como vantagens aos responsáveis, indica-se o controle e a priorização do tráfego da rede assim como o uso constante da banda através dos empréstimos entre classes. Uma possível desvantagem seria o período de tempo relacionado a transição para uma estrutura com QoS e a consequente adaptação dos usuários. A aplicação de QoS através de classes de serviço em uma estrutura de rede proporcionará aos responsáveis pela administração uma condição de controle preciso, flexível e confiável. Com isso, esse uso, torna-se fortemente indicado. REFERÊNCIAS T.I.S. 2014; 3 (1 ):

11 Controle de tráfego através de classes com Iptables e HTB STATO FILHO, A. Linux, Controle de Redes. Florianópolis: Visual Books, TANENBAUM, A. S. Redes de Computadores, tradução Vandenberg D. De Souza, 4ed. Rio de Janeiro: Elsevier, KUROSE F., ROSS, K. W. Redes de Computadores e a internet: uma abordagem top-down, tradução Opportunity translations; revisão técnica Wagner Zucchi. 5ed. São Paulo: Addison Wesley, RFC Disponível em: < rfc/rfc2474.txt>. Acesso em: 1 0 ago RFC Disponível em: < /rfc/rfc2475.txt>. Acesso em: 1 0 ago RFC Disponível em: < html/rfc1 91 8>. Acesso em: 25 ago Homepage do Projeto iptables/netfilter Disponível em < Acesso em 1 0 ago CUSTÓDIO, V. Igor. Modelagem de Tráfego e Qualidade de Serviço. aula introdutória, 25 de set - 02 de set de f. Notas de aula. Slides. Portal sobre Ipv6 do NIC.br. Disponível em Acesso em: 02 set de T.I.S. 2014; 3 (1 ): 58-68