(2) Comentários

Por Rafael Leão, 01/06/2010 07:00

Nesta semana publiquei um post sobre limitação de banda nos switches 3750, e agora vou mostrar um exemplo da mesma configuração em um Cisco PIX firewall 515E, versão 8.0(4).

Através de políticas de QoS, conseguimos implementar limitação de banda no PIX/ASA, para tráfego outbound, em determinada interface. Os passos para esta configuração são os mesmo do IOS em switches, apenas alguns comandos mudam.

Como podemos ver, há uma rede outside e uma inside somente, com um host cada um. Usei para realizar os testes, o software NetMeter.

Configuração do PIX

O PIX está pré-configurado para este lab da seguinte forma:

interface Ethernet0
nameif inside
security-level 100
ip address 172.16.1.10 255.255.255.0
!
interface Ethernet1
nameif outside
security-level 0
ip address 192.168.10.10 255.255.255.0
!
access-list acl_inside extended permit ip any any
access-list acl_inside extended permit icmp any any
access-list acl_outside extended permit ip any any
access-list acl_outside extended permit icmp any any
!
access-group acl_outside in interface outside
access-group acl_inside in interface inside

Como podemos observar, qualquer tráfego está permitido, nas duas interfaces, mas apenas para efeito de teste.

Agora vamos definir a configuração a ser aplicada.

1. Classificando o tráfego

Uma ACL define o tráfego selecionado…

access-list 700k_outside extended permit ip any any

… e um class-map, irá referenciá-la, para definir qual tráfego receberá determinada política.

class-map map_700k_outside
description 700k outbound interface outside
match access-list 700k_outside

2. Criar o Policy-Map

O policy-map aplica ao tráfego definido por class-maps, as suas respectivas ações. Neste caso, ao class-map map_700k_outside será aplicado uma política de taxa de output de 700Kbps.

policy-map pmap_700k_outside
class map_700k_outside
police output 700000 10500

O parâmetro 700000 significa a taxa de output em bits, e 10500 é o burst, em bytes.

3. Aplicando as políticas

Agora o último passo é aplicar a política à interface, em sentido outbound, com o comando ‘service-policy’. Neste caso, na interface outside.

service-policy pmap_700k_outside interface outside

Vamos aos testes…

Antes de mostrar os testes, uma coisa é importante dizer: estas configurações não serão aplicadas a conexões já existentes, como você poderá perceber a seguir…

Observe o gráfico abaixo:

À esquerda, podemos ver o tráfego normal entre os dois hosts, e do lado direito, o tráfego após aplicadas as configurações. O host 192.168.10.2 está copiando um arquivo de aproximadamente 4,7GB do host 172.16.1.2.

Conforme dito anteriormente, as políticas somente são aplicadas a novas conexões… por isso, após aplicar as configurações, usei o comando ‘clear conn’ para fechar todas elas… então comecei novamente a cópia do arquivo.

A nova conexão mostrada no output do PIX já está no ar com a nova política de tráfego aplicada.

É isso então! Espero ter ajudado…

Dúvidas?! Sugestões?! Críticas?! Todas serão bem vindas!! É só mandar nos comentários… valeu!

(7) Comentários

Por Rafael Leão, 27/05/2010 14:09

Este post traz uma configuração fácil de ser realizada em switches Cisco, para limitação de banda, em tráfego um switch Cisco Catalyst 3750, através de Policy-Maps.

Através de parâmetros configurados na Modular QoS CLI, selecionamos um determinado tráfego, e lhe aplicamos ações, baseadas nas políticas configuradas para ele. A limitação de banda pode ocorrer de duas formas: shaping ou policing.

Shaping vs. Policing

Antes de qualquer coisa, é importante sabermos a diferença entre estes dois métodos.

- Traffic Shapping retém pacotes que excedem a banda configurada para um buffer (queueing) e gradativamente vai os transmitindo, sem que o mesmo não sejam dropados; porém este buffer demanda de memória, e é sempre aplicada em sentido outbound.

- Traffic Policing propaga bursts (limites) quando o fluxo de pacotes atinge a banda máxima, no qual ações como dropar ou remarcar os pacotes é efetuada. Não há buffer, e a aplicação da política é em sentido inbound.

Mais informações aqui*. Agora, mão na massa!!!

* É necessário CCO para visualizar este documento.

Configurando Traffic Policing

Apenas 4 etapas são necessárias para alcançarmos nosso objetivo:

1. Habilitar QoS

Como esta configuração trata-se de parâmetros QoS, é necessário habilitar este recurso globalmente no switch:

mls qos

2. Classificar o tráfego

Definimos qual tráfego passará pelas políticas de banda. Primeiro criamos uma ACL:

access-list 111 permit ip any any

Depois definimos um class-map, ao qual a ACL será vinculada.

class-map match-all 8MB
match access-group 111

3. Criar o policy-map

O policy-map irá aplicar as políticas ao tráfego classificado anteriormente no class-map. O policy-map será nomeado Policy8MB.

policy-map Policy8MB

Agora entrando no modo de configuração de policy-map, iremos selecionar um class-map, e aplicaremos as respectivas ações. Neste caso, estaremos limitando a banda a 8Mbps o tráfego definido pelo class-map 8MB.

class 8MB
police 8000000 8192 exceed-action drop

Para entendermos melhor, os comandos acima, o parâmetro 8000000 significa a largura de banda medido em bits, e o ‘exceeded-action drop’, significa que os pacotes que ultrapassarem a banda de 8Mbps, serão simplesmente dropados.

4. Ativar a política

Por final, ativamos a política na interface, lembrando que é sempre ao tráfego inbound.

interface FastEthernet1/0/23
service-policy input Policy8MB

Está feito. Agora vou apresentar alguns testes que fiz, com as ferramentas Iperf – gerador de tráfego, NetMeter – medidor de banda de adaptador de rede, e o próprio MS-DOS.

Neste lab, temos duas máquinas windows conectadas a um switch 3750, em portas FastEthernet, somente com as configurações acima aplicadas. O host 10.1.0.11 está conectado à interface Fa1/0/23, e o 10.1.0.12, à Fa1/0/24.

Observe na primeira imagem, o output feito no Iperf do lado client.

Talvez para aqueles que não estão familiarizados com essa ferramenta, fique um pouco confusa a interpretação dos logs acima… mas eu vou tentar deixar o mais claro possível!

No primeiro comando, o Iperf client (10.1.0.11) está configurado para gerar 200Mbps de tráfego para o servidor 10.1.0.12. Como pode-se ver no output acima, a ferramenta consegue gerar 68,1 Mbps, sendo a taxa de transmissão REAL entre os dois foi de 64,4 Mbps.

Após isto, foram aplicados os comandos no switch, e o mesmo teste foi feito entre os dois. O client conseguiu novamente produzir 68,1Mbps, porém, a taxa real entre os dois foi de 6,7Mbps, segundo o reporte do servidor.

Com tráfego normal, o servidor reportou banda de 64Mbps, e após a regra, 6,7Mpbs, conforme o log acima.

Agora, vejamos o gráfico da placa de rede do client, gerado pelo NetMeter.

Bom é isso… espero ter ajudado. Qualquer dúvida mandem comentários!! Abraços e até mais…

Seja o primeiro a comentar

Por Daniel Ferianzzi Andriolo, 07/12/2009 09:54

Muito antes de existirem as redes convergentes suportando Voz, Vídeo e Dados sobre a plataforma IP, os conceitos e padrões de Voz já eram utilizados em larga escala e já estavam "maduros" o suficiente, de modo que as redes telefônicas se tornaram sinônimos de alta-disponibilidade e qualidade.

Atualmente estamos passando por um período de transição do mundo TDM para o mundo IP, de modo que cada vez mais o IP se aproxima do usuário final. Porém, esta transição se dará aos poucos, uma vez que os custos para a construção de uma infra-estrutura telefônica com os níveis de qualidade e suporte dos sistemas TDM ainda são muito altos e os protocolos utilizados precisam suportar todas as funcionalidades disponíveis no mundo TDM.

O que se pode ver hoje em dia nas empresas é a utilização do IP para a redução de custos em ligações locais e de longa distância através da utilização de operadoras VoIP, ou então é possível chegar a "custo zero" para chamadas entre filiais por exemplo, o que é chamado de "Toll bypass".

Neste tópico vamos relacionar alguns pontos fundamentais a serem levados em consideração na hora de projetar um ambiente de VoIP.

Largura de Banda

Quando contratamos um circuito de telefonia tradicional com qualquer operadora, estamos contratando um circuito dedicado para voz, ou seja, a largura de banda disponível nestas conexões será utilizada integralmente para a demanda de voz. Neste caso, o que deve-se levar em consideração é apenas a Quantidade de Usuários X Quantidade de Chamadas Simultâneas e então dimensionar a quantidade de canais/circuitos necessários.

Porém, quando decidimos integrar a funcionalidade de VoIP sobre os links de Internet que as empresas já possuem, além da questão de Quantidade de Usuários X Quantidade de Chamadas Simultâneas, é necessário levar em consideração também quais "codecs" de audio serão utilizados, qual será o tamanho do "payload" de voz que será inserido dentro de cada pacote, qual o tipo de conexão que será utilizado (MPLS, PPP, VPN, etc.), e então dimensionar a largura de banda necessária para suportar a quantidade de chamadas desejadas, reservando também uma quantidade de banda para o tráfego de outras aplicações.

Qualidade de Serviço (QoS)

Diferentemente do que acontece no mundo TDM, onde temos a largura de banda 100% dedicada para voz, o mundo IP compartilha a largura de banda entre todas as aplicações. O tráfego de VoIP não permite falhas na transmissão dos dados, ou seja, este tipo de tráfego não pode sofrer alterações como delay, jitter, perda de pacotes, etc.

Devido ao tráfego de VoIP ser do tipo "real-time", qualquer uma destas alterações implica na perda da qualidade das chamadas que utilizam esta tecnologia.

Para isto é que existem as políticas e funcionalidades de QoS, onde é possível fazer, em uma maneira bem simples de explicar, a marcação dos pacotes, seleção de filas e priorização do tráfego baseado na criticidade de cada aplicação.

Alta-Disponibilidade

A Infra-estrutura das operadores de telefonia possuem um nível de disponibilidade do sistema de 99,999% de "uptime" durante o ano. Para atingirmos este mesmo nível de disponibilidade da infra-estrutura de VoIP é preciso pensar em links redundantes, gateways, sistemas de UPS, políticas de roteamento de chamadas alternativo, etc., de modo que os equipamentos e recursos utilizados possam manter o ambiente ativo e funcional mesmo com a ocorrência de falhas em qualquer ponto da infra-estrutura.

Estes são apenas alguns pontos que devem ser levados em consideração para a construção de uma topologia VoIP. Conforme o cenário, a arquitetura e o modelo de topologia adotado, existem outros fatores que influenciam no design da solução.

Espero ter ajudado.
Até a próxima.