Arp on Cisco Redes

QoS Video – Networking 101

Sun, 08 Apr 2012 00:00:00 +0000

Olá caros,

Após nossos posts sobre QoS, gostaria de trazer mais um vídeo na qual adiciona mais alguns conceitos voltados para essa tecnologia. Esse vídeo é apresentado pelo famoso e engraçado Jimmy Ray, para qual explica um pouco sobre o QoS em Layer 2 e Layer 3.

Confira abaixo:

http://www.youtube.com/watch?v=LtNVmvv9ZUw&feature=player_embedded

Abs,
Rodrigo

QoS – Configuração de Police – Parte 4

Wed, 11 Jan 2012 00:00:00 +0000

Olá caros,

Como em nosso último post, falamos sobre o tratamento que existem nas filas e como os equipamentos podem trabalhar para efetuar suas operações, hoje iremos comentar um pouco sobre os métodos que temos para efetuar as configurações de police e suas funcionalidades.

Você poderia perguntar o que significa o termo police?

Police seria o termo utilizado pela Cisco, na qual podemos aplicar regras para nossa classe de QoS configurada. Essa police irá trabalhar neste exemplo especificamente para verificar o conform-action, exceed-action e violation-action. Existem outras polices relacionada à esta nomenclatura, porém não iremos tratar nesse post.

Traffic police libera você à controlar margem máxima de tráfego enviada ou recebida em uma interface. Frequentemente, essas configurações são aplicadas nas interfaces de borda da rede para limitar o tráfego de entrada e saída. O tráfego que cai dentro das margens dos parâmetros configurados é enviado, enquanto o tráfego que é excedido dentro dos parâmetros configurados é dropado ou enviados com uma prioridade diferenciada.

Devido ao ” traffic police ” meramente dropar ou re-marcar o tráfego excedente com uma prioridade menor, isso não coloca um ” delay ” para o conform ( não excedido ). Se o tráfego é marcado como dropado, a única coisa a se fazer seria re-transmitir esse pacote. O tráfego re-marcado pode ser colocado com uma prioridade menor dentro da fila que ele foi categorizado, efetuando assim uma medida menos agressiva para as informações que estão sendo processadas pelo seu equipamento.

O método de trabalho que o equipamento utiliza para fazer esses cálculos esta baseado no CAR ( committed access rate ). CAR olha para o tráfego recebido em uma interface, ou um subconjunto daquele tráfego selecionado pelos critérios da ” policy ” configurada, compara a sua taxa à configuração de um ” token bucket “, e então entra em ação com base no resultado ( por exemplo, drop ou remark IP precedência) .

Segue um exemplo sobre a atuação do CAR:

Quando mencionado sobre o token bucket ( balde tokens ), podemos ter confusões relacionados ao CAR. Uma tentativa de esclarecer qualquer confusão, é que o CAR (como o próprio nome descreve) é usado para a política que o tráfego flui naquela taxa de acesso. CAR faz isso com um token bucket, ou seja, um token bucket é um balde com tokens que são representados em bytes (1 byte = 1 token). O balde é preenchido com tokens a uma taxa configurada pelo usuário. Os pacotes que chegam para ser entregue, o sistema irá verificar o token bucket, e se houver tokens suficientes no balde para corresponder ao tamanho do pacote, os tokens são removidos e o pacote é encaminhando (conform-action). Se não há tokens suficientes, o pacote é descartado (exceed-action).

Vamos considerar um exemplo de policy, onde 500 bytes estão atualmente no token bucket. Um pacote é encaminhado exigindo 300 bytes. Os bytes são removidos do bucket, e o pacote é enviado, então antes que o bucket seja re-abastecido com mais tokens, outro pacote de 300 bytes é encaminhado. Devido ao bucket possuir apenas 200 bytes, o pacote não pode ser enviado e é descartado.

Veja abaixo a ilustração para exemplificar:

Esse método exercido através do token bucket é executado através de cálculos para verificar se o tráfego esta dentro dos parâmetros acordados ( SLA ). Police, no entanto, usa o parâmetro Be para especificar o número máximo de bytes que podem ser enviados durante um intervalo de tempo. Portanto, em uma configuração de police, se o Bc é igual ao Be, nenhum excesso de burst ( rajada ) irá ocorrer. Se o excesso bursting ocorrer a police irá considerar esse tráfego de excesso como ( exceed traffic ), ou seja, o CIR acordado foi violado.

Podemos fazer a relação entre Tc, Bc e CIR com a seguinte fórmula:

CIR = Bc / Tc

E podemos re-escrever a fórmula para:

Tc = Bc / CIR

Quando trabalhamos com uma configuração para qual usamos o violation-action, o IOS da Cisco irá utilizar dois bucket para gerenciar os tokens, ou seja, Bc e Be. Se o pacote pode ser usado utilizando o Bc ele estará dentro do conform, mas se ele não pode ser encaminhado usando Bc, ele irá ser encaminhado pelo Be, e estará dentro do exceed, e como última alternativa não podendo ser encaminhado pelo Bc e Be, ele será classificado como violado. Lembrando-se que o trafégo violado ainda pode ser transmitido usando uma combinação de bytes em ambos Bc e Be.

Veja abaixo a ilustração para o método de dois bucket:

Após essas menções vamos colocar alguns comando que podemos usar para a configuração explicada acima:

Neste exemplo podemos notar que a configuração foi executada para um average de 8000bits e um burst de 1000bytes.

Router(config)# class-map access-match
Router(config-cmap)# match access-group 1
Router(config-cmap)# exit
Router(config)# policy-map police-setting
Router(config-pmap)# class access-match
Router(config-pmap-c)# police 8000 1000 conform-action transmit exceed-action drop
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface fastethernet 0/0
Router(config-if)# service-policy output police-setting

Neste caso estamos trabalhando com dois buckets, mas colocando o exemplo com um exceed burst.

Router(config)# class-map access-match
Router(config-cmap)# match access-group 1
Router(config-cmap)# exit
Router(config)# policy-map police-setting
Router(config-pmap)# class access-match
Router(config-pmap-c)# police 8000 1000 1000 conform-action transmit exceed-action
set-qos-transmit 1 violate-action drop
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface fastethernet 0/0
Router(config-if)# service-policy output police-setting

Baseado nesses fatos conseguimos concluir que dependendo da sua necessidade, uma determinada configuração irá atender melhor sua demanda, ou seja, existem diversas formas de configurar seu ambiente, porém temos que escolher e definir aquilo que é importante para seu negócio.

Um video foi disponibilizado na nossa seção “ Video Aula “ para demonstrar o funciomento dessa configuração. Os arquivos de configurações podem ser obtidos da nossa seção Arquivos relacionado ao nosso primeiro laboratório parte 1.

PS.: Agradecimentos a Alis Silva pelo fornecimento do rack.

Espero que aproveitem e aguardo comentários 😉 .

Abs,
Rodrigo

Fontes:
Site Cisco – QoS
Cisco Press – Tips

QoS – Enfileiramento – Parte 3

Mon, 05 Dec 2011 00:00:00 +0000

Olá pessoal,

Conforme nosso último post, no qual foi mencionado sobre a marcação de pacotes dentro do cabeçalho IP ( ToS ), portanto hoje iremos trazer mais informações sobre QoS, mencionando sobre o método de filas que o equipamento utiliza para encaminhar seus pacotes.

Quando foi explicado sobre a marcação de pacotes e propriamente mencionado sobre as categorias de filas, ou seja, todo esse trabalho exerce uma funcionalidade para que no momento de recebimento desse pacote os equipamentos ( roteadores/swiches ) possam interpretar essa marcação ( preferência ) do pacote, sobre determinadas características em um plano de hardware queueing e software queueing.

Para um melhor entendimento segue um fluxograma de como funciona o tratamento de pacotes:

Para o propósito de hardware queueing:

Esse é o tipo de enfileiramento conhecido como TxQ (fila de transmissão), no qual ele usa o hardware e SEMPRE usa o mecanismo FIFO (First In First Out) e apenas quando essa fila fica cheia o software queueing será acionado. Nesta categoria estamos referenciando-se ao Tx Ring/ TX queue, fazendo dessa forma o enfileiramento quando a fila está cheia, e por sua vez o IOS habilita “queue” nesta interface.

Aqui podemos fazer uma analogia de como os pacotes chegam para uma determinada interface física de um equipamento. 😉

Quando tratamos do assunto de software queueing, teremos 6 categorias para classificar essas informações:

PQ – Priority Queue = Possui 4 filas FIFO, que são unidirecionais, e um pacote da fila em espera só entra em ação quando sua superior é esvaziada. Vantagens: Fornece prioridade restrita para um tráfego na classe. Desvantagem: pode sofrer de um fênomeno chamado: starvation (morte por insuficiência de alimentação).
CQ – Custom Queue = Possui 16 filas FIFO, que são unidirecionais, e um pacote da fila em espera só entra em ação quando sua superior é esvaziada.Vantagens: garante banda para aplicações menos críticas. Desvantagem: precisa criar uma política dentro da interface.
WFQ – Weighted Fair Queueing = Enfileiramento justo baseado em peso, ele atua de forma justa eliminando o fenômeno stavartion, ou seja, o primeiro da coluna de cada fila é expedido para o DEQUEUE e todos os pacotes da segunda coluna são expedidos e assim sucessivamente. Desvantagem: ideal para links até 2MBps, caso contrário muitos ciclos de CPU serão executados e não possui uma fila única de prioridade.
CBWFQ – Class-Based Weighted Fair Queue = Possui 64 filas FIFO, que são unidirecionais, e um pacote da fila em espera só entra em ação quando sua superior é esvaziada. Vantagem: recordista do número de classes, suporta até 64 para realizar controle de banda. Desvantagem: sem fila exclusiva de prioridade.
**LLQ – Low Latency Queue =**Conhecido por PQCBWFQ, devido a possuir uma fila PQ e um grupo em CBWFQ. Infelizmente isso é uma “sopa de letrinhas” 😀 Vantagens: ótimo para arquitetura AVVID da Cisco, excelente para aplicações real-time, garante banda e propicia a menor latência, não apenas para portas UDP/RTP mas qualquer outro tipo de porta. O seu único problema diz respeito a sua classificação não ser feita de modo automatizado, havendo a necessidade de configuração. Esse é o nosso método mais utilizado, porém se as classes não estiverem bem ajustadas conforme a realidade, podemos ter alguns problemas, que daí para frente teremos que realizar alguns troubleshootings!
IP RTP Priority = Conhecido por PQWFQ, por ser composto por uma fila PQ e o grupo de WFQ.Vantagens: ótimo para arquitetura AVVID da Cisco, garante banda e propicia a menor latência, não apenas para portas.

Abaixo segue uma tabela comparativa com as filas mais usuais que encontramos no nosso dia-a-dia:

Por padrão o FIFO é habilitado nas interfaces com a bandwidth acima de 2mbps e também por padrão o WFQ é habilitado nas interfaces com a bandwidth abaixo de 2Mbps

Baseado nessas informações temos mais um conceito que é obtido em nossas vídeo aulas, para qual tratamos de métodos para evitar o congestionamento. Na Cisco nós trabalhamos com três métodos, no qual chamamos de Tail DROP, WRED ( Weighted Randon Early Drop ) e CBWRED. Não vamos entrar muito em detalhes para não ficar extenso nosso post, mas podemos explicar rapidamente cada método:

Tail DROP = Descarte de pacotes baseado em hardware e software quando a fila está cheia, ou seja, novos pacotes que chegam na interface são dropados.
WRED = Característica do IOS utilizada para previnir que uma fila seja preenchida pela capacidade descartar o tráfego mais agressivamente quando a fila começa a se preencher. O descarte é feito baseado na prioridade de marcação, onde os pacotes de menor prioriodade terão maior chances de serem descartados. Dentro dessa características podemos chamar de ( minimum threshold, maximum threshold e mark probability denominator).

\
**CBWRED =**Mesma funcionalidade do WRED, porém podemos utilizar baseado por classe.

Como demos uma prévia sobre o conceito segue os comandos que podemos utilizar para fazer esse tipo de configuração.

Router(config-if)# class-map c1
Router(config-cmap)# match access-group 101
Router(config-if)# policy-map p1
Router(config-pmap)# class c1
Router(config-pmap-c)# bandwidth 48
Router(config-pmap-c)# random-detect dscp-based
Router(config-pmap-c)# random-detect dscp 8 24 40
Router(config-if)# service-policy output p1

Espero que vocês tenham gostado e aguardo comentários. 😛

Fonte:
Cisco Page – WRED
Cisco Page – Avoidance

QoS – Marcação de Pacotes – parte 2

Mon, 24 Oct 2011 00:00:00 +0000

Olá Pessoal,

Conforme anúncio vamos prosseguir com nossos estudos voltados para QoS. No último post havíamos tratado do assunto focando na tecnologia NBAR, e devido ao pontos levantados para execução do laboratório e definições de parâmetros, vamos discutir sobre o cabeçalho IP e a marcação do pacote.

O cabeçalho IP é composto por diversos campos, para qual define funcionalidades específicas para cada ” caixinha “. Todos esses valores são compostos por valores binários e podem ser visualizados através de uma ferramentas de monitoração ( WireShark ).

Segue as definições do cabeçalho IP, com uma relevância para a informação definida no ” ToS “.

Version: Contém o número da Versão IP ( 4 ou 6 ).
Tipo de Serviço (ToS): Valor binário de 8 bits que é usado para determinar prioridade no pacote.
Tempo de Vida (TTL): O valor TTL diminui em pelo menos um a cada vez que o pacote é processado por um roteador ( ou seja, a cada salto ).
Protocolo: Possibilita que a camada de rede passe os dados para camada superior ( 01 – ICMP ; 06 – TCP ; 17 – UDP )
CheckSum: Usado para a verificação de erros no cabeçalho do pacote.
Endereço de Origem: Endereço IP de Origem constituído de 32 bits ( x.x.x.x )
Endereço de Destino: Endereço IP de Destino constituído de 32 bits ( y.y.y.y )

Podemos obter maiores informações sobre todos os campos inseridos dentro do cabeçalho IP utilizando a RFC 791, para qual traz em detalhes cada campo informado dentro do cabeçalho, bem como os valores binários que podemos obter em cada ” caixinha “.

Com base nessa informação temos o formato do nosso IPV4 com 32 bits, para qual pode ser formado através de 4 conjuntos de 8bits cada. Neste formato podemos formar números decimais de 0 à 255. Não irei entrar nesse detalhe, pois iremos tratar desse assunto em outra ocasião, porém segue apenas como informação referenciando-se ao formato desse número que usamos hoje em qualquer lugar/equipamento.

Com base em todas as informações mencionadas acima, vamos apresentar os dados referentes ao tipo de marcação que posso executar dentro do cabeçalho IP para a ” caixinha ” ToS. Esse valor inserido exercerá uma funcionalidade para o pacote que viaja dentro da rede, fazendo com que a sua principal função é dar prioridade para determinados tipos de tráfego/aplicação.

O QoS é o acrônimo de ” Quality of Service “. Trata-se de uma nomenclatura genérica para designar um conjunto de algoritmos capazes de fornecer vários níveis de tratamento para diferentes tipos de tráfego na rede. O propósito dessa tecnologia é otimizar o uso da banda passante provendo um tráfego fim-a-fim eficaz e econômico. O QoS resolve a necessidade da aquisição de mais banda para a rede, pois supre a demanda de tráfego das LANs/WANs de forma inteligente e organizacional através dos mais diversos mecanismos que ele dispõe. Cada um desses tráfegos, merece um tratamento especial conforme suas características. Assim, é necessário que os cuidados especiais sejam obedecidos para que não ocorra possíveis problemas.

Os pontos chaves que o QoS pode tratar melhorando assim a performance da rede, poderia se basear em quatro ítens:

Jitter
Perda de Pacotes
Latência
Bandwidth

Devido aos ítens mencionados acima, foi criado em uma das características do QoS, a marcação do pacote através do DSCP ( Diff Service Point ) ou através de AF ( Assured Forwarding ).

DSCP = ele é composto de 6 bits, no qual temos em decimal a permutação de 2 elevado à 6 que é 64 valores possíveis, variando portanto de 0 à 63. Essa faixa de valores é que define literalmente a marcação dos pacotes. De antemão todo pacote BestEffort (BE) ou melhor esforço é tratado com DSCP 0 ou em binário 000000. Para a instância de voz sobre IP teremos o valor DSCP 46, para qual podemos consultar através da RFC 2598. Segue um exemplo:

AF = Define 4 classes para a proposta de fila, em conjunto com 3 níveis de probabilidade de drops dentro de cada fila. O formato que podemos seguir está baseado em AFxy , no qual esses valores vão implicar em uma tabela ( matriz ) 4 x 3. Os valores mais altos para o X irão ter preferência para serem transmitidos, e os valores maiores em Y terão uma probabilidade maior de drops dentro daquela mesma fila.

PS.: Quando temos a conversão do valor de AF para DSCP, podemos utilizar uma fórmula simples para calcular esse valor. Como mencionamos AFxy podemos fazer:

8x + 2y = valor decimal

Por exemplo: AF41 seria o valor decimal DSCP 34

Com isso podemos mostrar alguns exemplos utilizando as tabelas explicativas abaixo:

Nessa tabela podemos obter informações relacionadas a forma de marcação do DSCP e também como isso é disponibilizado através das categorias de classes. Lembrando-se que para essa marcação temos a disponibilização de 6 bits, podendo combinar diversos valores decimais.

Segue um exemplo da conversão desse valor:

IP Prec 5 (101) maps to IP DSCP 101 000

Essa tabela está referenciando-se ao formato do AFxy, para qual temos a matriz 4×3. Esse conceito pode ser consultados através da RFC 2597.

Baseado nas conversões demonstradas ao lado podemos perceber que temos a utilização apenas 5 bits, para qual é transformado para os valores mapeados em DSCP.

Todas essas informações podem ser consultadas através desse link.

A Cisco tem um modelo para qual podemos seguir dependendo da utilização e da demanda que irá ocorrer em nossa rede. A tabela abaixo pode mostrar o tipo de aplicação e em qual classe é recomendado trabalhar. Vocês poderiam se questionar sobre algumas informações contidas nessa tabela devido a não ter sido explicada anteriormente, mas a coluna ( Queuing and Dropping ), irei citar em outro post tratando especificamente desse assunto.

Essa tabela também esta referenciada através da RFC 4594, seguindo assim as padrões que podemos utilizar para essa tecnlogia.

Uma informação que acredito que seja importante quando falamos de QoS, estaria envolvido com o comportamento dos roteadores/switches. Vocês poderiam perguntar onde os equipamentos podem fazer essa classificação e marcação de pacotes?

Classificação = Somente ingress, e somente se a interface suportar o cabeçalho particular para aquele determinado campo.

Marcação = Somente egress, e somente se a interface suportar o cabeçalho particular para aquele determinado campo.

Em função desses conceitos existe uma vídeo aula disponibilizada em nossa seção, para a demonstração e visualização desses campos, com a marcação dos pacotes trafegados dentro da rede. Sempre recordando que os arquivos para a configuração dos equipamentos está disponibilizado em nossa seção de arquivos.

Os arquivos .txt podem ser utilizados dentro do GNS3, apenas tendo que montar a mesma topologia utilizada para nosso laboratório.

Para nosso próximo post irei trazer informações sobre o tipo de enfileiramento e os modelos que podemos utilizar para o melhor aproveitamento/performance da nossa rede.

Espero que gostem do post e aguardo comentários. 😉

PS.: Agradecimentos a Alis Silva pelo fornecimento do rack.

Abs,
Rodrigo

QoS com NBAR – parte 1

Fri, 23 Sep 2011 00:00:00 +0000

Olá pessoal,

Como todos sabem, o assunto de QoS é muito comentando nos dias de hoje, devido a grande utilidade e capacidade de controle que podemos exercer em cima dessa tecnologia. Dentro desse parâmetro irei trazer uma sequência de posts explicando essa tecnologia através de laboratórios com testes práticos.

Nessa primeira parte vamos aprender sobre o protocolo NBAR.

1) Introdução

A tecnologia de QoS foi difundida para que todos pudessem ter um maior controle de trafégo de sua rede, fazendo com que isso gere uma demanda de controle com muito mais granularidade. Em contrapartida, esses métodos exigem cada vez mais de profissionais com conhecimento, para que seja disponibilizado da melhor forma para sua rede.

Pensando dessa forma, a Cisco disponibilizou um recurso chamado NBAR, no qual pode trazer muitos benefícios para o nosso dia a dia. Esse protocolo tem a facilidade de fazer o reconhecimento das aplicações baseado na sua rede, portanto para determinadas aplicações o protocolo consegue identificar esses serviços, diminuindo a necessidade de um total conhecimento de sua rede.

Quando é mencionado a palavra QoS, todos imaginam que essa tecnologia pode resolver o problema de todos, porém precisamos pensar que esses recursos ajudam a melhorar a performance da rede, e para determinadas situações outros pontos precisam ser avaliados dentro da arquitetura de rede, como avaliação de capacidade de banda, avaliação do correto dimensionamento do equipamento, avaliação de desempenho para determinadas aplicações de negócio, análise interna dentro da sua rede local, otimização dentro do ambiente LAN e WAN.

2) Topologia

Nesta topologia a idéia é demonstrar uma rede com 3 roteadores e executar as configurações, referenciando-se as marcações de pacote conforme mostrado na figura.

Figura 1 – Topologia do Laboratório

Todos os equipamentos são Cisco e utilizando a tecnologia do protocolo NBAR para executar as configurações

3) Equipamentos

Neste laboratório estamos utilizando roteadores 1721, 1760 e 2611 disponibilizado em um rack. Para esse contexto iremos ter 3 modelos de IOS para que possamos utilizar funções de QoS com NBAR.

Segue os modelos de IOS utilizados para esse laboratório:

1721:
c1700-entbasek9-mz.124-15.T13.bin
1760:
c1700-ipvoicek9-mz.124-15.T13.bin
2611:
c2600-ipvoice_ivs-mz.124-25d.bin

Para melhor interpretação dos equipamentos podemos consultar as documentações através do site da Cisco. Para o modelo 1721, 1760 e 2611. Todos os equipamentos estão designados como “ End of Life ”.

Para conectividade dos circuitos WAN estamos utilizando placas com interfaces seriais. Toda a conectividade WAN tem a oferecer uma conexão ponto a ponto de um circuito dedicado com encapsulamento padrão utilizado pela cisco HDLC. A placa oferecida para essa conectividade é a WIC-2T que pode ser consultada através do site da Cisco.

4) Funcionalidade

Este laboratório consiste na demostração de uma tecnologia disponibilizada pela Cisco, na qual é referenciada ao protocolo NBAR. Através deste link você pode obter mais informações referenciando-se ao NBAR.

Dentro desse contexto podemos analisar alguns comandos que utilizamos neste laboratório através de documentações da Cisco, para qual pode facilitar o entendimento de todos os recursos disponibilizados. Esse protocolo foi desenvolvido para fazer o mapeamento da rede em produção, com a intenção de facilitar e montar uma estrutura de planejamento para o QoS. Uma configuração coletada automáticamente pode ser aplicada posteriormente nas interfaces desejadas da sua rede. As aplicações que são referenciadas para esse protocolo pode ser consultada através desse link, no qual vai trazer o tipo de protocolo, porta conhecida e qual versão de IOS vai suporta esse recurso.

Como o NBAR é um protocolo default do IOS nós podemos habilitar através de um comando, para que seja identificado o tipo de tráfego que esta passando por aquela interface. A linha de comando para esse recurso seria:

Router> enable
Router# configure terminal
Router(config)# interface ethernet 2/4
Router(config-if)# ip nbar protocol-discovery
Router(config-if)# end

Nessa linha de raciocíonio podemos utilizar esse recurso para eventuais “ troubleshooting “, com a capacidade de demonstrar ao seu cliente que o maior consumo de tráfego esta sendo utilizado em uma determinada aplicação. Neste exemplo podemos avaliar quais aplicações estão sendo descobertas pelo protocolo e qual o consumo em bytes/packets.

Router# show ip nbar protocol-discovery interface FastEthernet 6/0

 FastEthernet6/0
                            Input                    Output
   Protocol                 Packet Count             Packet Count
                            Byte Count               Byte Count
                            5 minute bit rate (bps)  5 minute bit rate (bps)
   ------------------------ ------------------------ ------------------------
   igrp                     316773                   0
                            26340105                 0
                            3000                     0
   streamwork               4437                     7367
                            2301891                  339213
                            3000                     0
   rsvp                     279538                   14644
                            319106191                673624
                            0                        0
   ntp                      8979                     7714
                            906550                   694260
                            0                        0
   .
   .
   .
   Total                    17203819                 151684936
                            19161397327              50967034611
                            4179000                  6620000

Para os comandos de match podemos consultar esse documento e para as validações referentes ao protocol-discovery podemos avaliar por esse documento.

Em nosso laboratório as configurações exercidas para reconhecimento dos protocolos exemplicados foi através desse método:

Router(config)# class-map ICMP
Router(config-cmap)# match protocol icmp
Router(config)# class-map HTML
Router(config-cmap)# match protocol http
Router(config)# class-map FTP
Router(config-cmap)# match protocol ftp

Gostaria de ressaltar que nesse exercíco estamos exercendo a marcação de pacote na saída do circuito de internet ( R1 ) conectado com o mundo exterior, porém essa técnica não é valida para nosso mundo real, pois em nenhum momento o acesso a rede mundial vai entender a marcação desse pacote. Para um entendimento e disponibilidade de recursos internos o exemplo relacionado a HTTP dentro da rede interna seria de mais fácil disponibilização para a demostração do laboratório.

Toda a conectividade desses circuitos foram exercidadas através de uma largura de banda 1,544Mbps e dentro desse valor suposições de valores para cada classe foi definida, reservando as maiores bandas para o tráfego que teria maior demanda nessa simulação. Por padrão do IOS, quando são definidos “ class-map “ e posteriormente criado a “ policy-map “, a banda que fica definida para efeito de cálculo no momento de aplicar “ service-policy “ é de máximo 75% da banda configurada para a interface.

Com isso fiz a definição:

1500K – ( .75 * 1500 ) = 375K

Nesse caso iremos utilizar para efeito de cálculo 1125kbps. Com isso os valores designados para cada tipo de protocolo foi:

HTTP = 500Kbps
SMTP = 150Kbps
FTP = 190Kbps
Management = 10Kbps
ICMP = 10Kbps
Default = 265Kbps

Lembrando-se que esses valores podem ser definidos da melhor forma que você achar dentro da sua rede. Os valores definidos para este exercício foi devido a facilidade de conseguir demonstrar através de um acesso simples ao protocolo HTTP.

Como o protocolo é default do IOS, podemos ter aplicações que não conseguem serreconhecidas através desse recurso automático, portanto devemos fazer o download de um arquivo que a Cisco designou como sendo PDLM ( Protocol Description Language Module ). O NBAR analisa os pacotes e compara eles com as regras existentes no PDLM. Para fazer o download do arquivo segue a instrução ( apenas usuários cadastrados podem fazer download desse arquivo )

Após o download podemos configurar conforme explicação no documento da Cisco:

Router> enable
Router# configure terminal
Router(config)# ip nbar pdlm flash://citrix.pdlm
Router(config)# end

Para validação se o arquivo foi habilitado dentro do equipamento, podemos avaliar através:

Router# show ip nbar pdlm

The following PDLMs have been loaded:
flash://citrix.pdlm

Não é sempre que o PDLM padrão fornecido atenderá nossa necessidades. Você pode querer adicionar suporte para um protocolo de rede específico, que precisa ser classificado e marcado no QoS ou para efeitos de acompanhamento personalizado. Essa pergunta é respondida com a “ PDLM custom “, o arquivo personalizado é chamado de custom.pdlm, que tem que ser carregado e então modificado conforme as exigências do protocolo.

O IOS que pode ter esse recurso personalizado foi construído na versão 12.X, e a Cisco tem introduzido essa personalização, onde usando “ ip nbar custom NAME [parameters] “ comando, você pode definir seus protocolos customizados. Para vocês que querem saber sobre como o arquivo foi carregado e como pode ser alterado segue o link.

Outro recurso que podemos visualizar através do NBAR seria o mapeamento de portas que existem para as aplicações que temos definidas pelas RFCs, porém eu tenho a capacidade de definir para uma determinada aplicação em qual porta ela poderia trabalhar alterando esse parâmetro. Por padrão segue um output resumido:

R2_1721#sh ip nbar port-map
port-map bgp                      udp 179
port-map bgp                      tcp 179
port-map bittorrent               tcp 6881 6882 6883 6884 6885 6886 6887 6888
port-map citrix                   udp 1604
port-map citrix                   tcp 1494
port-map cuseeme                  udp 7648 7649 24032
port-map cuseeme                  tcp 7648 7649
port-map dhcp                     udp 67 68
port-map directconnect            tcp 411 412 413
port-map dns                      udp 53
port-map dns                      tcp 53
port-map edonkey                  tcp 4662
port-map exchange                 tcp 135
port-map fasttrack                tcp 1214
port-map finger                   tcp 79
port-map ftp                      tcp 21
port-map gnutella                 udp 6346 6347 6348
port-map gnutella                 tcp 6346 6347 6348 6349 6355 5634
port-map gopher                   udp 70
port-map gopher                   tcp 70
port-map h323                     udp 1300 1718 1719 1720 11720
port-map h323                     tcp 1300 1718 1719 1720 11000 - 1999
.
.
Omitted

Para executar a alteração da porta para o serviço desejado devemos fazer no modo de configuração global:

R2_1721(config)#ip nbar port-map sqlnet tcp 63000 63001

Um video foi disponibilizado na nossa seção “ Video Aula “ para demonstrar o funciomento desse protocolo. Esses vídeos foram disponibilizados em 3 partes, devido a quantidade de minutos para esse laboratório. Os arquivos de configurações podem ser obtidos da nossa seção Arquivos.

No próximo post irei demonstrar através do WireShark o cabeçalho IP ( ToS ) com a marcação dos pacotes exercidas dentro do nosso ambiente de estudos.

PS.: Agradecimentos a Alis Silva pelo fornecimento do rack.

Abs,
Rodrigo