(Mais uma semana começando) Tirar uma certificação nunca é fácil. O conteúdo costuma ser extenso, o material para estudo é caro, nem sempre os assuntos são fáceis, e no caso de redes ainda tem o fato de muita gente não ter acesso a equipamentos para poder praticar. Felizmente hoje temos a disposição inúmeras opções de simuladores/emuladores de equipamentos de rede. Packet Tracer, GNS3, IOU Web e UnetLab são algumas das opções de emuladores. O Packet Tracer é o mais simples de usar, mas também o mais limitado. Na realidade ele é apenas um simulador. O GNS3 foi a primeira plataforma de virtualização de roteadores Cisco que tive acesso, muito anos atrás… Tinha vários probleminhas e consumia muito recurso. Depois com a opção do GNS3 VM ficou bem melhor. E então apareceu o L2/L3 IOU (Jesus… escrevi sobre isso em 2011… achava que fazia uns dois anos) e o IOU Web. Pra mim, aqui tivemos um salto de qualidade. Com estes emuladores criamos os equipamentos de rede em uma máquina virtual, bem mais estável e consumindo muito menos CPU e memória. No caso de dispositivos Cisco especificamente, além dos roteadores passamos a poder emular switches. Por fim conheci o Unetlab, que segue na mesma linha do IOU Web, mas foi escrito do zero, pensando na estabilidade e também na agregação de equipamentos de múltiplos fabricantes. Unetlab – EVE Recentemente o Unetlab lançou a nova versão de seu software, que agora chama-se EVE – Emulated Virtual Environment. Já vinha usando o Unetlab há pelo menos um ano, e na última semana instalei o EVE (donwload para a máquina virtual pode ser feito aqui). De cara da para perceber que houve um preocupação com a interface, que ficou mais bonita. O software parece bem estável, e também notei algumas funcionalidades rodando melhor, como L3 Etherchannel em switches Cisco. No meu caso especificamente utilizo o emulador para estudar e testar funcionalidades de equipamentos Cisco. O Unetlab-EVE permite a emulação de roteadores e swiches (IOS), NX-OS, ASA, ISE, WSA e ESA, entre outros. No meu notebook consigo criar redes com até 30 roteadores, o que tem sido suficiente. Mas esta plataforma ainda permite a emulação de equipamentos de outros fabricantes, como A10, Aruba, Arista, Brocade, CheckPoint, Juniper e Mikrotik, para citar alguns. Outro item interessante é que o EVE permite a utilização por múltiplos usuários. Ou seja, cada um que loga no software tem sua pasta, com seus labs/equipamentos. Além de baixar o EVE, você precisa conseguir as imagens dos equipamentos que pretende emular. Nada que não encontre na internet. Curso de laboratórios avançados e aluguel de simulador Se você você nunca teve acesso a este tipo de software ou acha complicado preparar o ambiente, uma ótima opção é o curso online do Netfinders Brasil. Neste curso, gravado, você vai aprender instalar e configurar o ambiente, e ainda montar os laboratórios e ter acesso aos softwares para emulação (e se falar que viu aqui no Brainwork, ganha 10% de desconto). Outra opção que achei muito interessante, também disponibilizada pelo Netfinders Brasil, é o aluguel de um servidor EVE na nuvem. Por 29,99 por mês podemos acessar o EVE remotamente e criarmos os laboratórios que quisermos. Muita gente acaba comprando um servidor para fazer a emulação, quando está estudando. Mas esta opção de aluguel me parece mais vantajosa. Por exemplo, se alugar o ambiente por 2 anos, você gastaria 720 reais. Bem menos que pagaria em qualquer servidor montado, e ainda não precisaria gastar com energia e, passaria a ter acesso de qualquer lugar. De qualquer forma, mais uma opção. Mas informações: Unetlab Canal Unetlab Youtube Curso Unetlab Aluguel de Servidor na Nuvem Até a próxima.
Problema no clock afeta produtos Cisco (e outros fabricantes)
(Xiiiii) A Cisco anunciou que em novembro de 2016 tomou ciência de um problema no componente responsável pelo clock de alguns equipamentos (segundo a CRN o problema é no chip Atom da Intel). Segundo o comunicado, este componente defeituoso foi utilizado em switches, roteadores e firewalls, e pode fazer com que estes equipamentos parem de funcionar depois de 18 meses de uso, muito embora o mais provável é que o problema se manifeste com mais frequência após 3 anos de funcionamento. Os produtos que forem afetados, se desligados não serão mais iniciados e não há procedimento de recuperação. Clientes com contrato serviço com a Cisco poderão fazer a troca do equipamento defeituoso, quando o problema ocorrer ou mesmo antes, desde que comprovado que o produto faz parte do lote problemático. Produtos afetados: NCS1K-CNTLR NCS5500 Line Cards IR809/IR829 Industrial Integrated Services Routers ISR4331, ISR4321, ISR4351 and UCS-E120 ASA 5506, ASA 5506W, ASA 5506H, ASA 5508, and ASA 5516 Cisco ISA3000 Industrial Security Appliance MX 84 Nexus 9000 Series N9K-C9504-FM-E/N9K-C9508-FM-E/N9K-X9732C-EX MS350 Series O fornecedor responsável pelo componente defeituoso é parceiro de outras empresas, e assim outros fabricantes de equipamentos de rede também foram afetados (HP, Juniper, Pfsense/Netgate, são algumas das empresas afetadas e que já se manifestaram). Mais informações sobre este problema neste link. Até a próxima.
Resumo OSPF
(Complicadíssimo) O OSPF – Open Shortest Path First, é um protocolo de roteamento dinâmico, criado pelo IETF e que utiliza o algoritmo SPF – Shortest Path First, também conhecido como Dijkstra, nome de seu criador. Ele é do tipo link state, e assim, ao invés de manter uma tabela com todas as rotas aprendidas, ele mantém uma tabela com o estado de todos os links de sua área. A partir daí ele consegue calcular o melhor caminho para cada rede. O OSPF é o protocolo de roteamento interno (IGP) mais utilizado, por não ser proprietário e também por sua escalabilidade e robustez. Ele é mais pesado do que o RIP e o EIGRP, mas isso não é grande problema atualmente, considerando-se poder de processamento dos equipamentos existentes. Vamos a um resumo dos itens básicos (mas relevantes) do OSPF. Áreas Adicionam hierarquia e aumentam a escalabilidade da rede. Cada área é um LSA Flooding Domain. Mudanças em uma área nem sempre requerem recálculo SPF fora desta área. Todos os roteadores em uma área tem a mesma visão da topologia. Roteamento entre áreas é semelhante ao feito por protocolos Distance Vector. Área 0 (backbone) é usada para sumarizar informações entre áreas. E tráfego entre áreas precisa passar pela área 0. As áreas precisam ser contíguas. Outras áreas (sem ser 0) são chamadas non backbone area. Tipos de Roteadores Backbone Router: Tem links (ao menos um) na área 0. Internal Router: Roteador com links apenas em uma área (sem ser a área 0). ABR – Area Border Router: Tem links na área 0 e em outras áreas. Usado para sumarizar informações entre área 0 e demais áreas (faz o cálculo SPF para cada área que está conectado). ASBR – Autonomous System Boundary Router: Tem interface no domínio OSPF (qualquer área) e ao menos um link fora do domínio OSPF (rodando EIGRP, RIP,…). Usado para fazer redistribuição. Router ID Router ID (RID) pode ser configurado automaticamente (escolhe a loopback com maior IP, e na ausência de interfaces loopback escolhe qualquer outra interface com maior IP). Para ser usada como router ID a interface não pode estar em shutdown, mas pode estar down. O Router ID não precisa ser um IP existente no roteador, não precisa ser anunciado no processo e não precisa haver rota para ele. Cada processo OSPF usa um RID diferente. Se mudarmos o RID o processo OSPF é reiniciado. Quando o processo OSPF é reiniciado um RID diferente pode ser escolhido (desde que não tenha sido configurado manualmente). Hello Pacotes Hello são enviados para o endereço multicast 224.0.0.5 (todos os roteadores OSPF), ou como unicast, dependendo do tipo da rede. Servem para identificar outros roteadores falando OSPF no segmento. Verificam a visibilidade bidirecional, e a “saúde” do neighbor. Validam parâmetros de configuração: Autenticação. Se os roteadores estão na mesma subnet (IP primário da interface). Se os roteadores estão na mesma área e se a área é do mesmo tipo. Se não há RID duplicado. O Hello Timer e Dead Timer precisam ser igual entre os vizinhos. Dead Timer = 4x Hello Timer. Se um destes itens não bater os roteadores não formam adjacência. Estado do Vizinho Down: Estado inicial do OSPF. O neighbor também é considerado down quando o roteador deixa de receber os hellos. Para ser considerado down o neighbor precisa já ter sido visto. Attempt: Estado válido apenas em redes NBMA ou point-to-multipoint non-broadcast. Neste tipo de rede o neighbor é imediatamente colocado em Attempt e contatato por Hello. Se o neighbor não responder no Dead Interval é colocado como Dead. Init: Quando o roteador recebe um Hello, mas seu próprio RID não está no Hello (eu enxergo o vizinho, mas será que o vizinho me vê?). 2-Way: Quando o roteador recebe um Hello e seu próprio RID está no Hello. Ou seja, ambos os roteadores se enxergam. Em caso de redes multiaccess, os neighbors ficam neste estado (menos com o DR e com o BDR). Exstart: Quando o roteador sai de Init/2-way significa que deverão ficar Full Adjacentes, e este é o início da troca do Database Description. Exchange: Nesta fase o Database Description é trocados. No Database Description está a lista de LSAs que cada roteador conhece. Loading: O roteador está fazendo o download dos LSAs do vizinho. Full: Todos os LSAs foram baixados do respectivo vizinho. DR/BDR/DROthers Em redes multiaccess (broadcast ou não) temos a eleição do DR – Designed Router, e do BDR – Backup Designed Router. Neste tipo de rede os roteadores formam adjacência (ficam com o status “Full”) somente com o DR e o BDR. Os demais vizinhos ficam com status DROTHER. Os roteadores enviam updates para o DR e para o BDR usando o IP multicast 224.0.0.6, e então o DR envia o update para todos os roteadores (multicast destinado à 224.0.0.5). É eleito DR o roteador com maior prioridade (1 – 255, padrão = 1) no segmento. Se houver empate é eleito DR o roteador com maior RID. O segundo roteador com maior prioridade/RID é eleito BDR. Interfaces com prioridade 0 não participam da eleição. Se o DR falhar o BDR muda para DR e uma eleição para BDR é realizada. Não há preempt (há controvérsia). Ou seja, se o DR anterior voltar, ele não assumirá o papel de DR até que ocorra uma nova eleição e ele seja escolhido. Tipos de Rede OSPF O tipo de rede/interface impacta diretamente no funcionamento do OSPF, conforme podemos ver na tabela abaixo. Custo O OSPF usa apenas a banda como custo (Custo = Banda de Referência / Banda da Interface). Podemos definir o custo por neighbor ou por interface. Roteadores não precisam ter a mesma banda de referência (definida no processo OSPF), mas não faz sentido terem referências diferentes. Nem sempre o custo é levado em conta para a escolha do melhor caminho. Mais informações sobre OSPF: Design Guide Configuration Guide Até a próxima.
1º Mobility Brazil Conference–Começo promissor
Aconteceu nos últimos dias 6 e 7 de fevereiro o primeiro Mobility Brazil Conference, em São Paulo. Este foi o primeiro evento do tipo no Brasil (pelo menos o primeiro que tive notícia), e o intuito dos organizadores foi discutir assuntos relacionados à tecnologia e fortalecer a comunidade WiFi. Foram abordados temas como a importância das redes WiFi, segurança e como evitar redes mal projetadas. Dicas para site survey, como aproveitar melhor o espectro WiFi, tipos de antenas e como smartphones tratam o WiFi foram outros assuntos abordados, sempre com o foco técnico. Tivemos palestrantes participando localmente, como Flávio Corrêa (CCIE Wireless, CWNA, CWSP, CWDP e um dos organizadores), e também palestrantes remotos, com destaque para Blake Krone (CCIE Wireless, CWNE, nostringsattachedshow.com), Eddie Forero (ACCP, ACMX, CWNE, badfi.com), Jussi Kiviniemi, VP da Ekahau, direto da Finlândia, com uma apresentação fazendo analogia entre WiFi e bar (e por incrível que pareça a analogia funciona muito bem), e ainda Jérôme Henry, líder técnico na Cisco, para citar alguns. Eventos neste formato são muito comuns em outras áreas (segurança é um bom exemplo), mas não havia nada neste sentido para os profissionais e entusiastas de redes sem fio no Brasil. Os organizadores (Anderson Freire, Flavio Corrêa, Gerardo Mendel, Gustavo Mastroianni e Yuri Mecca) fizeram um ótimo trabalho, montando uma agenda de bom nível e garantindo o perfeito andamento das apresentações. A ideia é que o evento volte a ser realizado (provavelmente no próximo ano), com mais divulgação e com mais participantes. Que venha o 2º Mobility Brazil Conferente! Até a próxima.
Configurando MSTP–Multiple Spanning Tree Protocol
(Dá-lhe camada 2) O MSTP – Multiple Spanning Tree Protocol, é uma variação do Spanning Tree Protocol, criado pela Cisco e posteriormente padronizado pelo IEEE. Assim como o STP, o função do MSTP é evitar a ocorrência de loop de camada dois na rede. No MSTP temos a separação das instâncias spanning tree e VLANs, coisa que não ocorre quando usamos o PVSTP ou o RPVSTP. Com estes protocolos cada VLAN gera uma instância STP, o que causa maior consumo de recursos nos switches e limita o número de VLANs que podem ser utilizadas. Os switches Cisco 2960, por exemplo, suportam 128 instâncias do STP. Ou seja, apenas 128 VLANs podem ser criadas com a utilização do STP. Caso mais VLANs sejam criadas, estas VLANs adicionais não utilizam o STP para prevenção de loop. E esse é o grande benefício do MSTP. Em ambientes com um grande número de VLANs faz-se obrigatório o seu uso, pois com ele podemos dizer quais e quantas VLANs fazem parte de uma dada instância de spanning tree. Por exemplo, poderíamos ter 200 VLANs em um 2960 e duas instâncias STP. Neste caso poderíamos mapear 100 VLANs em uma instância do MSTP e outras 100 VLANs em outra instância. Com isso as 200 VLANs estariam usando o STP e protegidas contra loops. O MSTP usa o conceito de region para definir a área de atuação. Quanto switches tem o MSTP configurado com o mesmo nome, revisão e mapeamento de vlans para instâncias, eles pertencem a mesma região MSTP. Com relação as instâncias, podemos criá-las arbitrariamente, e automaticamente é criada uma instância 0, onde as VLANs são mapeadas inicialmente (antes de fazermos o mapeamento para a instância desejada). Configurando o MSTP Vamos considerar a topologia abaixo, com a configuração inicial listada na sequência. Script para configuração inicial para os 3 switches. BrainSW01#conf t BrainSW01(config)#hostname BrainSW01 !BrainSW02 BrainSW03 BrainSW01(config)#vtp mode transparent Device mode already VTP Transparent for VLANS. BrainSW01(config)#vlan 1-10,100-110,200-210 BrainSW01(config-vlan)#int range eth0/0 – 1 BrainSW01(config-if-range)#switchport trunk encapsulation dot1q BrainSW01(config-if-range)#switchport mode trunk BrainSW01(config-if-range)#end BrainSW01# Temos 30 VLANs e vamos dividi-las em 3 instâncias. A configuração abaixo deve ser aplicada nos 3 switches. BrainSW01#conf t Enter configuration commands, one per line. End with CNTL/Z. BrainSW01(config)#spanning-tree mode mst BrainSW01(config)#spanning-tree mst configuration BrainSW01(config-mst)#name MyMST BrainSW01(config-mst)#revision 1 BrainSW01(config-mst)#instance 1 vlan 1 – 100 BrainSW01(config-mst)#instance 2 vlan 101 – 200 BrainSW01(config-mst)#instance 3 vlan 201 – 300 BrainSW01(config-mst)#end BrainSW01# Note que o mapeamento que foi feito já engloba VLANs que não foram criadas. Caso essas VLANs sejam criada posteriormente elas serão associadas as instâncias conforme o que foi definido. Também é importante perceber que se uma VLAN fora do range definido for criada, ela será associada a region default (MST 0). Agora vamos definir a root bridge para cada região (o switch 1 será root para as VLANs da região 1 e 2, e o switch 3 será o root para a região 3). BrainSW01#conf t BrainSW01(config)#spanning-tree mst 1-2 priority 0 BrainSW01(config)# BrainSW03#conf t BrainSW03(config)#spanning-tree mst 3 priority 0 BrainSW03(config)# Podemos verificar nossa configuração com os comandos abaixo: BrainSW02#show spanning-tree mst configuration Name [MyMST] Revision 1 Instances configured 4 Instance Vlans mapped ——– ——————————————————————— 0 301-4094 1 1-100 2 101-200 3 201-300 ——————————————————————————- BrainSW02#show spanning-tree mst 1 ##### MST1 vlans mapped: 1-100 Bridge address aabb.cc00.0200 priority 32769 (32768 sysid 1) Root address aabb.cc00.0100 priority 1 (0 sysid 1) port Et0/0 cost 2000000 rem hops 19 Interface Role Sts Cost Prio.Nbr Type —————- —- — ——— ——– ——————————– Et0/0 Root FWD 2000000 128.1 Shr Et0/1 Desg FWD 2000000 128.2 Shr BrainSW02#show spanning-tree mst 2 ##### MST2 vlans mapped: 101-200 Bridge address aabb.cc00.0200 priority 32770 (32768 sysid 2) Root address aabb.cc00.0100 priority 2 (0 sysid 2) port Et0/0 cost 2000000 rem hops 19 Interface Role Sts Cost Prio.Nbr Type —————- —- — ——— ——– ——————————– Et0/0 Root FWD 2000000 128.1 Shr Et0/1 Desg FWD 2000000 128.2 Shr BrainSW02#show spanning-tree mst 3 ##### MST3 vlans mapped: 201-300 Bridge address aabb.cc00.0200 priority 32771 (32768 sysid 3) Root address aabb.cc00.0300 priority 3 (0 sysid 3) port Et0/1 cost 2000000 rem hops 19 Interface Role Sts Cost Prio.Nbr Type —————- —- — ——— ——– ——————————– Et0/0 Altn BLK 2000000 128.1 Shr Et0/1 Root FWD 2000000 128.2 Shr BrainSW02# Como podemos ver, além da questão da preservação de recursos, o MST também nos permite fazer o balanceamento do tráfego entre os caminhos de camada 2. Mais sobre o Multiple Spanning Tree Protocol aqui. Até a próxima.
QoS–Policing e Shaping (Parte 3)
(Ufa) Para finalizar esta série de posts sobre QoS, vamos falar dos mecanismos usados para controlar a taxa de transmissão em uma interface. Tanto o Policing quanto o Shaping são configurados através do MQC, e identificam infrações (excessos) da mesma forma. Eles geralmente diferem, no entanto, na resposta as violações. O Policing normalmente descarta o excedente, enquanto que o Shaping atrasa o excesso de tráfego, usando um buffer para armazenar os pacotes e moldar o fluxo quando a taxa de dados é maior do que o esperado. Para isso o Traffic Shaping monitora o bit rate em que os pacotes são enviados, e se exceder o permitido os pacotes são colocados em uma fila (shaping queue), para posterior transmissão. O Shaping só pode ser configurado na saída da interface. Importante notar que quando fazemos o Shaping não estamos mudando a velocidade da interface. Ou seja, se configurarmos um shape de 1 Mbps em uma interface de 2 Mbps, a interface continuará trabalhando a 2 Mbps. O que nos leva a pergunta: Como atingimos a velocidade (Shaping) configurada? No caso acima o Shaping faria com que a interface transmitisse apenas metade do tempo. Por exemplo, vamos considerar que o roteador dividiu cada segundo em 10 partes (chamadas Tc – Time interval, em milissegundos), ele vai então transmitir nas partes 1, 3, 5, 7 e 9 e nas partes 2, 4, 6, 8 e 10 não haverá transmissão. O tráfego normal, enviado a cada Tc, é chamado Bc – Committed Burst. E ainda podemos configurar o Shaping para que permita um “bursty” (excedente). Esta função permite que após um período de transmissão onde a velocidade não atingiu o CIR – Committed Information Rate, mais tráfego (chamado Be – Excess Burst) possa ser enviado por um período de tempo (Tc). Estes mesmos conceitos aplicam-se ao Traffic Policing, que pode ser configurado tanto na entrada quanto na saída de interfaces e sub-interfaces. Assim como o Shaping, o Policing monitora o bit rate e então toma ações com base nesta informação. E ai que está a diferença. Podemos configurar o roteador para transmitir os pacotes que estiverem conformes (dentro da velocidade – que não passou da quantidade de bits – Bc, em um dado Tc), marcar os pacotes que excederem a velocidade mas ainda estão dentro do limite de excesso (Bc + Be em um dado Tc) e descartar os pacotes quando a o tráfego for maior do que Bc + Be em dado Tc (este tipo de política é chamado de Single Rate, 3 Colors). Outras opções seriam termos apenas duas ações configuradas (transmite e drop), criando assim uma política Single Rate, 2 Color. Por fim, temos a Policy do tipo Dual Rate, 3 Color, onde além do CIR temos também o PIR – Peak Information Rate. Neste caso os pacotes que estiverem abaixo do CIR estão conformes, os que estiverem entre o CIR e o PIR são considerados acima do contrato (exceed) e os que estiverem acima do PIR estão violando o contrato. Configurando Traffic Policing Voltando a nossa topologia de exemplo, vamos configurar o Policing na entrada da interface E0/0, limitando a velocidade a 2 Mbps. Nesta interface já tínhamos uma policy-map (MARCA) configurada, responsável por fazer a marcação dos pacotes. Vamos remove-la da interface e aplicá-la em uma outra policy-map (2MBPS), onde definiremos a banda e as ações. Policing: 2 Mbps Conforme-action: Transmite Exceed-action: Marca os pacotes com DSCP CS0 (Default) e transmite Violate-action: Descarta os pacotes QoS#conf t QoS(config)#policy-map 2MBPS QoS(config-pmap)# class class-default QoS(config-pmap-c)#police cir 2000000 conform-action transmit exceed-action set-dscp-transmit default violate-action drop QoS(config-pmap-c-police)# service-policy MARCA QoS(config-pmap-c)#exit QoS(config-pmap)#exit QoS(config)#interface Ethernet0/0 QoS(config-if)# no service-policy input MARCA QoS(config-if)# service-policy input 2MBPS QoS(config-if)#end QoS# Vamos executar um ping a partir do roteador Origem, e então ver o resultado da nossa política no roteador QoS. Origem#ping 2002:CC2E::100 repeat 1000 size 1000 Type escape sequence to abort. Sending 1000, 1000-byte ICMP Echos to 2002:CC2E::100, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!! Success rate is 99 percent (994/1000), round-trip min/avg/max = 1/1/3 ms Origem# Note que tivemos algumas perdas no ping, resultado da política (drop). Agora vamos ver as estatísticas no roteador QoS. QoS#sho policy-map interface et0/0 Ethernet0/0 Service-policy input: 2MBPS Class-map: class-default (match-any) 1004 packets, 1014320 bytes 30 second offered rate 89000 bps, drop rate 0000 bps Match: any police: cir 2000000 bps, bc 62500 bytes, be 62500 bytes conformed 632 packets, 637112 bytes; actions: transmit exceeded 366 packets, 371124 bytes; actions: set-dscp-transmit default violated 6 packets, 6084 bytes; actions: drop conformed 57000 bps, exceeded 31000 bps, violated 0000 bps Podemos ver que dos 1004 pacotes recebidos na interface E0/0, 632 estavam conformes, 366 excederam o contrato e 6 pacotes foram dropados (justamente a quantidade de “.” no output anterior). Também podemos verificar outra informação importante: bc 62500 bytes, be 62500 bytes. É com base nesta configuração que o roteador identifica o que é conform, exceed ou violated. Neste exemplo, se forem enviado até 62500 bytes em um intervalo de tempo, consideramos que o tráfego está conforme. Se enviar até 125000 bytes (Bc + Be) em Tc, consideramos que o tráfego excedeu, e se passar disso o tráfego violou o contrato e por isso será dropado (de acordo com o que foi configurado). A fórmula para saber Tc é: Tc =Bc/CIR. Usando o exemplo acima temos Tc = (62500 x 8)/2000000. Tc = 0,25. Ou seja, a cada 0,25 segundos podem ser enviados 62.500 bytes (Bc), e eventualmente podem ser enviados 125.000 bytes (Bc + Be) em 0,25 segundos. Neste caso o roteador fez o cálculo automaticamente, mas podemos fazer esta parametrização manualmente, no comando police, dentro policy-map que define a banda. Configurando Traffic Shaping Sabendo que o roteador da operadora está configurado para fazer o Policing (e descartar o tráfego excedente), podemos configurar um Shaping do lado “cliente” para não excedermos a banda (e consequentemente não ter tráfego dropado). Vamos configurar
