EIGRP sobre Frame Relay

O frame-relay, diferente de circuitos ponto a ponto, cria “caminhos virtuais” ou VCs (Virtual Circuits) entre os dispositivos finais (CPE – Customer Premise Equipment), os quais são identificados pelo endereço de camada 2 do frame-relay chamado DLCI – Data Link Connection Identifier.

Cada DLCI deve ser mapeado ao endereço de camada 3 de seu vizinho, processo que pode ser realizado manualmente ou dinamicamente utilizando-se o Inverse ARP. Portanto, em uma rede frame-relay cada conexão será identificada com um DLCI, o qual deve ter mapeado o endereço IP do dispositivo remoto para que os pacotes possam ser enviados até ele através de uma nuvem frame-relay através de um DLCI local. Por isso o nome ARP Inverso ou Inverse ARP, pois no ARP mapeamos um endereço IP remoto ao MAC remoto e aqui mapeamos um endereço de camada 2 local (DLCI local) ao endereço de camada 3 remoto.

A comunicação entre os dispositivos finais ou CPEs e a nuvem frame-relay se dá através de um protocolo local que roda entre o CPE e seu switch frame-relay chamado LMI, lembrando que normalmente esse parâmetro não precisa ser configurado para IOSs superiores à versão 11.3.

O frame-relay pode ser conectado em dois tipos de topologia: “partial mesh” (malha parcial) ou “full-meshed” (malha completa). A diferença entre uma rede full-meshed para uma partial meshed é que na primeira todos os PVCs possíveis devem ser criados entre os CPEs. Uma malha parcial muito utilizada na prática é a Hub and Spoke, representada na figura abaixo. Nessa rede temos um roteador central chamado de Hub e vários routers remotos chamados Spokes,

Portanto, quando o roteador Hub quiser enviar pacotes para o Spoke A, por exemplo, ele enviará os quadros via circuito virtual do frame-relay identificando com o DLCI 102. Esses quadros serão encaminhados ao switch local onde o Hub está conectado e direcionado para o Spoke A que receberá  as informações no DLCI 201, portanto quando ele for responder ao Hub ele enviará as informações para o DLCI 201 e o Hub as receberá no DLCI 102. Se dois spokes quiserem trocar mensagens eles deverão encaminhar ao Hub para que ele sirva de intermediário nessa topologia.

Em termos de vizinhança nessa topologia ela será estabelecida apenas entre o roteador Hub e cada um dos spokes, sendo que os spokes não estabelecerão vizinhanças entre si, pois para que haja esse estabelecimento seriam necessários PVCs criados entre eles. Portanto, em um “show ip eigrp neighbors” (tabela de vizinhança) o Hub terá como vizinho os spokes A, B, C e D, porém cada Spoke terá apenas o Hub em sua tabela. As topologias em malha completa não têm restrições com relação ao funcionamento ou estabelecimento de vizinhanças no EIGRP, pois haverão PVCs criados entre todos os CPEs.

 É importante lembrar que para as topologias em malha parcial, especialmente Hub and Spoke, quando conectadas com interfaces ou subinterfaces multiponto essas ficam sujeitas ao Split Horizon. Na prática ocorre que o Hub irá conhecer as redes dos spokes, porém os spokes conhecerão apenas as redes do Hub, pois a rede dos vizinhos spokes será bloqueada pelo split horizon. Por exemplo, quando o spoke A anuncia suas redes ao Hub ele não poderá retransmitir esse mesmo anúncio para os DLCIs 103, 104 e 105, pois em uma rede NBMA todos os DLCIs estariam na mesma interface, subinterface e consequentemente na mesma rede ou sub-rede IP, portanto o split horizon não permitirá o encaminhamento do anúncio na mesma interface. Para resolver esse problema podemos utilizar subinterfaces ponto a ponto ou então desativar o split horizon no roteador Hub.

Analise a topologia da figura abaixo onde as interfaces estão configuradas com o frame-relay padrão nas interfaces físicas e R1 é o roteador HUB com DLCIs apontando para R2 e R3 conforme tabela de encaminhamento do switch frame-relay FR1.

Se nenhuma configuração extra for realizada os roteadores R2 e R3 apenas visualizarão suas próprias redes e a rede de R1 e não conseguirão visualizar em suas tabelas de roteamento as redes um do outro. Veja exemplo do show ip route no roteador R2 abaixo e note que a rota para R3 está faltando:

Agora vamos desativar o split horizon em R1 para que as rotas possam ser aprendidas por R2 e R3 com o comando dentro da interface serial 0/0 “no ip split-horizon eigrp 100"

Note que após o comando imediatamente o EIGRP faz uma resincronização (resync) passando as redes para os vizinhos R2 (192.168.1.2) e R3 (192.168.1.3). Após esse comando veja o que acontece em R2. Primeiro o EIGRP avisa um resincronismo e um “gracefull restart”, ou seja, a vizinhança está sendo reinicializada. Após isso com o show ip route já conseguiremos visualizar a rede de R3 10.0.2.0 na tabela de roteamento.

Lembre-se que a configuração padrão do frame-relay nas interfaces Cisco faz com que todas as interfaces estejam na mesma sub-rede, chamada de rede NBMA ou Non-broadcast Multiple Access Network. Aqui nesse detalhe é onde na prática devemos tomar cuidado na escolha de que opção devemos utilizar para a configuração das interfaces frame-relay, pois ela pode ser:

Atualização/Instalação IMC Intelligent Management Center 7.0 para 7.1

Instalando e Atualizando IMC

Para instalar o IMC no Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 ou Windows Server 2012 R2, primeiramente modifique a conta de usuário no painel de controle.

• Abra o Control Panel em Start menu e clique System and Security.
• No Action Center, clique em Change User Account Control Settings. 
• Dentro do User Account Control Settings, troca opção de the Choose when to be notified about changes to your computer  para  Never notify.

Importante:

Antes de atualizar a plataforma do IMC, é necessário baixar todos os pacotes de atualização do site da HP antes de instalá-los.

Preste atenção especial para a seção "Compatibilidade de Plataforma" em seu readme.

Se um pacote de atualização não está disponível para um componente de serviço, a HP

não recomenda a atualização da Plataforma IMC.

Caso você queira prosseguir com a instalação você pode remover o modulo antes de atualizar a plataforma IMC. 

Importante destacar que quando o modulo é removido, seus dados são perdidos.

Se o agente de monitoramento de implantação exibe uma lista de componentes incompatíveis com a nova versão da Plataforma IMC, você deve baixar e atualizar os pacotes para esses componentes antes de continuar a atualização processo.

Todos os módulos  devem usar v7.1 ou superior para trabalhar com IMC PLAT 7.1.

Após a Plataforma do IMC ser atualizada necessário atualizar os módulos, como WSM, UAM, EAD, NTA / UBA, APM, e SOM. 

Antes de instalar ou atualizar um modulo na plataforma do IMC, por favor, verifique a seção"Compatibilidade de Plataforma" nos arquivos de readme. 

Caso contrário, pode IMC não ser iniciado. 

Para a matriz de compatibilidade, veja os arquivos readme dos componentes de serviço.

Se você receber a mensagem "Upgrade JVM falhou ..." durante a atualização , elimine a pasta no diretório jre common \ \ da instalação do IMC e continue a atualizar.

Atualizando IMC

1. É necessário fazer o backup do banco de dados do IMC na guia Environment em Deployment Monitoring Agent

2. Copie manualmente o diretório de instalação do IMC para um caminho de backup.

3. Pare IMC em Deployment Monitoring Agent.

4. Clique em Install na guia Monitor em  Deployment Monitoring Agent.

5. Selecione as janelas/Install/Components no diretório de atualização de pacote e clique em OK.

6. Clique em OK na caixa de diálogo mensagem pop-up.

7. Clique em Start em Upgrade Commom Components na caixa de diálogo Componentes comuns para atualização.

8. Depois de componentes comuns são atualizados, clique em Close.

9. No modo de implantação distribuída, é necessário parar Deployment Monitoring Agent no servidor principal e reiniciar o Deployment Monitoring Agent em cada servidor subordinado. 

Clique em Yes na caixa de diálogo mensagem pop-up para atualizar os componentes comuns em cada servidor subordinado.

10. A implantação do Monitoring Agent exibe todos os componentes que precisam ser

atualizado. Clique em OK para iniciar a atualização.

11. No modo de implantação distribuída, é necessário atualizar todos os componentes implantados em cada servidor subordinado.

12. Após todos os componentes serem atualizados, você pode iniciar todos os processos no Deployment Agente de Monitoramento.

Para obter mais informações sobre a instalação e atualização de procedimentos, consulte IMCGetting started Guide no IMC deployment guides.

Backup

O armazenamento de informação é um pilares da Tecnologia de Informação (TI). Enormes quantidades de informação digitais são criadas a todo momento.
Organizações devem assegurar que os dados certos estejam nos lugares corretos no tempo preciso.

• Backup : consiste na cópia de arquivos/blocos destinados a recuperação de dados apagados ou corrompidos. 

É muito importante  que os profissionais de TI  saibam avaliar as tecnologias e entender requisitos visando oferecer uma implementação bem-sucedida da solução de backup e recuperação.

A principio devemos entender o conceito de RTO e RPO para entender sobre conceitos da solução:

• RPO (Recovery Point Object): Período tolerável de perda de dados em caso de falha ou desastre.    

RPO irá especificar o intervalo de tempo que deverá ocorrer entre dois backups (frequência).

• RTO (Recovery Time Object): Tempo gasto no processo de recuperação. (restabelecimento do serviço)

RTO baixo irá minimizar o tempo de inatividade e será necessário combinar diferentes soluções de backup, influenciando o tipo de mídia a ser utilizada na retenção das informações.

Importante destacar que o período de retenção das informações deve ser levado em consideração as necessidades operacionais do setor do negocio e a necessidade requerente de espaço para armazenamento que acarreta na elevação do custo da solução.

Classificação das politicas de backup.

Backup Full / Completo / Normal

Característica desse backup é que copia todos os arquivos de um volume (diretório/pasta/partição/dico) em determinando tempo

Usaremos a analogia de "check box" para marcar as pastas que serão modificadas ou criadas no momento do backup, observe o comportamento de cada pasta em sua modalidade de backup.



Pasta A (já existia e não houve alteração)                      

              Após o Backup Full                 

Pasta B (Criada)

               Após o Backup Full                

Pasta C  (Modificada)

              Após o Backup Full                   


Após o Backup full podemos observar que a modalidade de backup, copia todas os arquivos do diretório, desmarcando ou alterando/retornando  o bit responsável pela informação que o arquivo participou do último backup.


Na figura acima estamos demostrando o agendado para ocorrer um backup full a cada domingo.

 Características do backup full:

• Restauração rápida pois precisa apenas a última cópia full (mais recente).
• Porém é o backup mais demoradona sua execução de copia, pois todos os arquivos serão copiados.
• Há redundância de dados o que resulta em um maior volume de armazenamento.

Backup Incremental 








Usaremos a mesma analogia de "check box" para marcar as pastas que serão modificadas ou criadas no momento do backup, observe o comportamento de cada pasta em sua modalidade de backup.


Pasta A (já existia e não houve alteração)                      

           


    Após o Backup incremental   (Não teve nenhuma ação)



Pasta B (Criada)

   Após o Backup incremental         

Pasta C  (Modificada)

     Após o Backup incremental         

Após o Backup incremental podemos observar que a modalidade de backup, copia apenas os arquivos alterados ou criados, desmarcando ou alterando/retornando o bit responsável pela informação que o arquivo participou do último backup.



Na figura acima estamos demostrando como pode ser uma estrutura de volume de dados em um backup do tipo incremental.

 Características do backup incremental:

• Restauração lenta pois precisa de todos backup incrementais até o momento da perda do dado e a última cópia full (mais recente).

Ex. caso a o arquivo seja apagado na quinta-feira, será necessário o backup incremental da quarta-feira,terça-feira,segunda-feira e o backup completo de domingo. 

• Porém é o backup mais rápido na sua execução de copia, pois somente os arquivos criados ou alterados serão copiados.
• Não há redundância de dados o que resulta em um maior volume de armazenamento.

Backup Diferencial

Usaremos a mesma analogia de "check box" para marcar as pastas que serão modificadas ou criadas no momento do backup, observe o comportamento de cada pasta em sua modalidade de backup.


Pasta A (já existia e não houve alteração)

           



     Após o Backup Diferencial   (Não teve nenhuma ação)     


Pasta B (Criada)

     Após o Backup Diferencial               

Pasta C  (Modificada)

     Após o Backup Diferencial               

Após o Backup diferencial podemos observar que a modalidade de backup, copia apenas os arquivos alterados ou criados igualmente a modalidade de backup incremental, porém após o backup diferencial  a marcação não é alterando/retornando o bit responsável pela informação que o arquivo participou do último backup, dessa forma na próxima janela de backup será efetuado o backup  das pastas B e C e mais alguma outra pasta criada ou alterada.   

Na figura acima estamos demostrando como pode ser uma estrutura de volume de dados em um backup do tipo diferencial.

Importante observar que o volume de dados será crescente.

Características do backup incremental:

• Restauração relativamente lenta pois precisa do ultimo backup diferencial no momento da perda do dado e a última cópia full (mais recente).

Ex. caso a o arquivo seja apagado na quinta-feira, será necessário o backup diferencial da quarta-feira e o backup completo de domingo. 

• Porém é o backup rápido na sua execução de copia, pois somente copia os arquivos criados ou alterados.
• Ocupa um volume de armazenamento maior que o incremental. Diferenciais mais recentes tendem a ser maiores que os anteriores.

  

Porque usar switch Layer 2 na camada de acesso ?

Vejo os altos números de desempenho dos atuais switches de acesso. O tempo passa, a tecnologia amadurece ( tendendo a diminuir de preço) e hoje estamos em um estágio em que é bem comum que as portas de acesso (Ethernet) nos novos projetos sejam de 1Gbps (apesar de que 100Mbps por porta continuam sendo mais do que suficientes para a grande maioria dos casos).

Convém ter o cuidado com a armadilha dos grandes números… Digo isso, pois noto uma demasiada valorização de aspectos quantitativos (dentro daquela perspectiva cômoda do “quanto mais, melhor”), em detrimento de uma análise mais criteriosa de funcionalidades que fazem a diferença no projeto como um todo.

Existe uma tendência a simplificar excessivamente o assunto, provavelmente influenciada pela idéia errônea de que “para montar uma LAN é só ligar o switch e conectar os cabos“… (Antes de tirar uma tal conclusão, lembre-se que “um cabo errado pode ser a origem de um loop”…)

Existe ainda a percepção histórica de que um core L2 é rápido e uma opção correspondente com L3 seria lenta, apesar de possuir mais funcionalidades. No que concerne a uma tal visão , vale dizer que, apesar de ter sido correta muitos anos atrás, os equipamentos evoluíram de modo a tornar as taxas de encaminhamento (pps) em L2 e L3 virtualmente indiscerníveis (mas, certamente, com um custo maior associado ao último). E, graças a este progresso tecnológico, é possível agora usar L2 ou L3 conforme sejam mais adequadas para um determinada área da rede (este é o chamadodesign multilayer)

Se há a intenção de produzir projetos mais consistentes, é importante um melhor entendimento do modelo de camadas (acesso, distribuição e núcleo) ou, eventualmente a combinação das duas últimas, no caso de redes menores. A orientação básica pode ser resumida na adoção de L3 para conexão da distribuição ao núcleo e L2 para ligar a distribuição ao acesso . Isso garante a disponibilidade, convergência rápida e isolamento providos pelo L3, sem perder a mobilidade e simplicidade do acesso L2.

As principais motivações para adotar uma abordagem multilayer são listadas a seguir:

• Separação funcional: cada camada desempenha um papel bem definido no conjunto da solução
• Modularidade: há blocos de projeto bem definidos, o que facilita o entendimento da topologia lógica (incluindo plano de endereçamento e esquema de numeração de VLANs).
• Facilidade de expansão:  quando há necessidade de acrescentar portas para usuários, não é necessário fazer um novo projeto. Se a organização em camadas foi utilizada desde o início, fica bem mais fácil acrescentar um novo bloco de acesso e prover as portas necessárias
• Padrões de tráfego determinísticos: dado que os servidores estão centralizados e que as estações de usuários se conectam a swiches de acesso, é mais fácil prever os fluxos de aplicações e planejar a utilização dos uplinks.
• Criação de pequenos domínios de falha: a demarcação clara da função de cada camada facilita o isolamento e a resolução de problemas.
• Equilíbrio entre recursos L2 e L3: isso permite extrair o melhor de cada uma das tecnologias.
• A utilização de roteamento (L3) entre distribuição e núcleo, permite balanceamento de carga, convergência rápida e maior nível de controle (limitação da topologia L2).

Algumas características relevantes da camada de acesso (nível 2):

• Ponto de ingresso na Rede : PCs, telefones IP, impressoras, etc.
• Controle de acesso por porta à rede deve começar aqui (IEEE 802.1x/NAC): Autenticação, Autorização e Accounting para usuários e equipamentos.
• Funcionalidades de Segurança integradas à Rede : Port security, DHCP Snooping, Dynamic ARP Inspection, IP Source Guard, Private VLANs, apenas para citar algumas.
• Idealmente com uplinks duplicados para a camada de distribuição (alta disponibilidade).
• Por ser um processo fim-a-fim, QoS deve começar aqui: e deve contemplar parâmetros de nível 2 (CoS), nível 3 (DSCP) e nível 4 (portas TCP e UDP).
• Supressão de broadcast, multicast e unknown unicast
• IGMP Snooping, de modo a evitar que portas físicas que não contém “receivers” para um determinado grupo, recebam desnecessariamente tráfego Multicast (otimização de IP Multicast na rede de switches nível 2)
• Otimização de Spanning Tree (IEEE 802.1D, IEEE 802.1w, IEEE 802.1S)
• Mapeamento entre VLANs (L2) e sub-redes IP (L3). O default-gateway para os hosts em um determinada VLAN fica na camada de distribuição ou distribuição/core (no caso de um design usando o conceito de “collapsed backbone”)
• Capacidade de identificação automática de “endpoints”, principalmente os de multimídia (LLDP e LLDP-MED)

Algumas características importantes da camada de distribuição:

• Agregação de vários switches de acesso (para criar um “bloco de acesso” em que há mobilidade dentro de uma VLAN/subnet)
• Uplinks para o CORE a partir de um bloco de acesso (switch de distribuição) em vez de uplinks partindo de cada switch de acesso
• Recomenda-se o uso de “Layer 3 switching” para esta camada
• Evita que o CORE tenha que estabelecer múltiplas adjacências e o isola em relação a problemas na camada de acesso.
• Funcionalidades de proteção do protocolo Spanning tree (definição de STP Root Bridge, evitar que switches de acesso tentem se tornar a Root Bridge)
• Sumários de Roteamento, convergência rápida, load sharing através de caminhos redundantes
• HSRP (Hot Standby Router Protocol) ou VRRP (Virtual Router Redundancy Protocol) ou GLBP (Gateway Load Balancing Protocol) para redundância de “default gateway”
• Disponibilidade e load balancing (Rapid Per-VLAN Spanning Tree, Per-VLAN 802.1w)
• Roteamento Multicast usando protocolos PIM e IGMP (interação host <> router)
• Listas de controle de acesso para controlar a conexão entre subnets IP.

Alguns aspectos importantes a considerar na camada de CORE :

• Sinônimo de camada 3 no conceito multilayer
• Representa o backbone da Rede:  interconexão dos blocos de distribuição e ligação com a WAN e o Data Center.
• Em redes grandes, a camada de CORE é normalmente usada para evitar “full-mesh” dos switches de distribuição
• Foco em Desempenho e Estabilidade versus complexidade— “less is more in the core”
• Camada de CORE separada ajuda a prover expansibilidade para crescimento futuro.
• Vale a pena fazer um design de CORE que seja independente da tecnologia de conexão (GigEtherntet, 10GigEthernet, CWDM, Sonet, Dynamic Packet Transport, etc.)

Tendo discutido as características dos projetos multilayer, listamos a seguir uma série de benefícios associados ao uso de switches nível 2 na camada de acesso. Além das grandes vantagens de preço trazidas por esta opção, (particularmente pelo número de switches de acesso em um projeto ser bem maior que os das demais camadas), vale mencionar:

• Facilidade de conexão de novos usuários ( tornando o acesso plug and play)
• Aumento da mobilidade de usuários entre switches (isso é particularmente importante em ambientes que empregam 802.1x/NAC para atribuição dinâmica de VLAN). Aliás, o design de NAC torna-se muito mais complexo quando o acesso é L3.
• Roteamento fora da camada de acesso. Esta função é exercida pelo switch de distribuição ou CORE. Isso diminui o número de adjacências de protocolos de roteamento e aumenta a expansibilidade da Rede.
• O fato de não se ter roteamento no acesso também contribui para a estabilidade da rede: menor número de mudanças na topologia de roteamento e redução de recálculos por parte dos protocolos dinâmicos.
• Multicast para os usuários é controlado via IGMP Snooping (seleção de portas físicas que vão receber tráfego multicast em uma dada subnet) e não via roteamento Multicast (o que obrigaria a criação de adjacências do protocolo PIM em cada switch de acesso). Mais uma vez, ressalte-se aqui a preocupação em reduzir complexidade e aumentar estabilidade.
• As atividades de filtragem (através de listas de controle de acesso) se concentram um nível acima (distribuição), tornando-se, portanto, muito mais facilmente gerenciáveis.
• Particularmente no que concerne à segregação de voz e dados, é muito mais simples fazer o controle na camada de distribuição (em vez de configurar ACLs em cada switch de acesso).

Concluímos o breve texto ressaltando que, apesar de nível 2 no acesso significar que não se usa roteamento IP em tal camada,vários  outros recursos que vão muito além do nível 2 continuam disponíveis:

• Os switches L2 modernos dispõem de capacidade de filtragem (por meio de ACLs) que levam em conta campos do cabeçalho IP e combinações de portas de serviço (TCP/UDP).
• As tarefas de classificação de pacotes (no contexto de Qualidade de Serviço - QoS) podem ser feitas com base em critérios como DSCP (L3), endereços IP de origem/destino, portas TCP/UDP.
• É possível gerenciar os switches via IPv6 (sem necessidade de rotear IPv6).
• Muitos dos switches L2 atuais podem ser configurados para responder aprobes de validação de SLA (Service Level Agreement) que permitem testar operações TCP, UDP e ICMP.
• Há vários modelos de switches L2 que permitem fácil diferenciação (e separação lógica) entre telefones IP e computadores, através do recurso de Voice VLAN.

Segurança para Comunicações Unificadas: o que esperar do seu Firewall ?

Segue uma matéria muito boa escrita no Blog de nosso amigo Alexandre Moraes.

Em um artigo no blog do Alexandre Moraes, foi apresentado os conceitos básicos de VoIP, Telefonia IP e Colaboração (http://wp.me/p1loe7-c2) e caracterizamos o papel das redes convergentes como plataforma de negócios. Não é necessária uma longa reflexão para concluir que um tal apelo negocial vem acompanhado da necessidade de se prover segurança para o transporte integrado de vídeo, voz e dados.

Seguindo o clássico raciocínio de que é recomendável criar “camadas de segurança”, resumimos a seguir algumas iniciativas relevantes no que concerne à Segurança de Telefonia IP:

• Separação das VLANs de voz e dados nas portas de acesso dos switches LAN (usando o conceito de “Voice VLAN“)
• Prover proteção contra as técnicas que podem induzir um redirecionamento de tráfego em ambientes de switches LAN (mesmo sem necessidade de configuração explícita de espelhamento de portas). Exemplos de ataques em um tal categoria são ARP Cache Poisoning(combatido com Dynamic ARP Inspection) e emulação do servidor DHCP (combatido com DHCP Snooping).
• Controle de acesso entre subredes associadas a voz e dados.
• Criptografia da voz para evitar a remontagem das conversações eventualmente capturadas
• Proteção dos servidores que implementam as soluções de colaboração usando firewalls
• Proteção das entidades de sinalização (Call Managers, gateways, gatekeepers, etc) por meio de firewalls.

A discussão de todas as técnicas que acabamos de elencar exigiria muitos artigos e, portanto, concentraremos nossa atenção na última delas. E uma das motivações para uma tal escolha é precisamente esclarecer o significado da expressão “inspeção avançada dos protocolos de telefonia“, sempre presente nos descritivos técnicos dos firewalls disponíveis no mercado (mas quase nunca detalhados).

A esta altura, alguém que já conheça os princípios básicos de segurança de redes pode estar se perguntando: ” - Se voz e vídeo são apenas novas aplicações que usam o transporte convergente, por que precisariam de um tratamento especial ao atravessar um firewall…? A resposta está relacionada à forma com que os protocolos de sinalização de Telefonia IP (que podem usar transporte TCP ou UDP) negociam as portas UDP destinadas aos canais de mídia (RTP/RTCP):

• Se os firewalls inseridos entre os elementos de sinalização não entenderem perfeitamente a natureza do protocolo em uso (SCCP, SIP, H.323 ou MGCP), não serão capazes de criar corretamente as conexões RTP/RTCP. E, bem sabemos, deixar um intervalo de portas UDP previamente aberto não é uma boa idéia se você tem intenção de implementar uma política de firewall que tenha alguma dignidade… 
• Apesar de sempre mencionarmos a criação das conexões, também é vital (tanto sob a ótica de segurança como de liberação de recursos) que elas sejam terminadas dinamicamente. Para materializar tal possibilidade é importante que o firewall suporte timeouts diferenciados para as sessões de controle e mídia.
• Os protocolos de sinalização de voz tipicamente incluem o endereço IP em seu payload (camada de aplicação). Desta forma, caso as comunicações se estabeleçam em ambientes com NAT ou PAT, é fundamental que o firewall tenha consciência de tais características para que possa efetuar as traduções de endereços IP nas camadas 3 e 7 simultaneamente.
• Um dos atrativos de Telefonia IP é a capacidade de prover confidencialidade para a voz transportada, usando, por exemplo, sinalização sobre TLS (Transport Layer Security) para então derivar os canais Secure RTP (SRTP) para mídia (vide figura 3). O desafio em uma tal situação é que muitos firewalls não conseguem entender a sinalização cifrada e teriam, portanto, que deixar um grande número de portas UDP (associadas ao SRTP) abertas. Isso, em termos práticos, significa abrir mão da criptografia de voz ou do stateful firewall.

Para auxiliar na compreensão dos principais conceitos da integração de firewalls a projetos de UC , passaremos agora à análise de alguns modelos de topologia: um primeiro, contendo apenas telefones IP, e um mais abrangente, prevendo a existência de gateways de voz e comunicação com a rede pública de telefonia (PSTN). Por último (Figura 3), examinaremos a situação de agregar criptografia a fluxos de voz que atravessam o firewall.

A Figura 1 ilustra um cenário simples em que dois IP Phones SCCP (Skinny), que residem em  redes diferentes, precisam se comunicar em uma topologia protegida por um Cisco ASA. A figura caracteriza a situação inicial (apenas sinalização) e um momento seguinte, com uma ligação estabelecida. (Note que o firewall identifica claramente as portas associadas a áudio). Para fins práticos, vale citar que, além da permissão para registro dos telefones e execução de chamadas (porta de serviço TCP/2000 na direção do telefone ao CUCM ), você precisará criar regras que permitam o uso dos serviços auxiliares:

• TFTP (dos telefones para o CUCM): neste caso, as atribuições principais do servidor TFP são a transferência de arquivos de firmware e configuração para os telefones.
• Resolução DNS do nome do CUCM ( e eventuais serviços complementares).
• DHCP é a escolha tradicional para endereçamento dos IP phones. A opção DHCP 150 informa os telefones sobre o endereço IP do servidor TFTP. Tal funcionalidade pode ser habilitada por interface no próprio Cisco ASA.

Figura 1: Cenário simples usando sinalização SCCP (Skinny)

Há ambientes com complexidade bem superior ao que foi mostrado na Figura 1, exigindo alta capacidade de coordenação por parte do firewall. Isso costuma ocorrer porque, mesmo depois de ter migrado toda a sua rede para telefonia IP, você ainda precisará integrá-la com as redes tradicionais de telefonia, fato este que exige a inclusão dos gateways de voz . Se você estiver usando o conjunto de padrões H.323, por exemplo, a primeira tarefa adicional é decidir se os gateways se comunicarão diretamente com o CUCM ou se haverá o uso de um gatekeeper.

Dentre os protocolos definidos no framework H.323, alguns são de particular relevância para redes VoIP/IPT:

• H.225: responsável por criação e finalização de chamadas em ambientes H.323. As mensagens H.225 usam a porta TCP/1720.
• H.245: responsável por flow control, negociação de funcionalidades e alocação dos canais de mídia, dentre outras atividades. A porta TCP usada para o H.245 é derivada da inspeção H.225.
• H.225 RAS: As mensagens de Registration, Admission and Status (RAS) são usadas nos ambientes em que o roteamento de chamadas de voz é executado de forma centralizada por um gatekeeper H.323. A porta UDP/1719 é reservada para o RAS.

Os dois modelos H.323 brevemente descritos são ilustrados na Figura 2. A principal razão para incluir tal exemplo está relacionada com a tentativa de enfatizar que o firewall deve ser capaz de analisar as várias etapas de sinalização e manter o processo de chamadas o mais transparente possível para os usuários finais.  Note que há várias entidades de sinalização envolvidas (CUCM, gateways, gatekeeper), as quais normalmente estão situadas em diferentes interfaces do firewall. Além disso, o objetivo final (após inspecionar as várias mensagens de controle) é estabelecer a chamada entre os telefones (os quais também podem estar localizados em interfaces diferentes).

Cumpre ainda ressaltar que o Cisco Unified Communications Manager (CUCM) pode operar simultaneamente como controlador de chamadas que usem qualquer dos protocolos mencionados (SCCP, SIP, H.323 e MGCP), o que permite seu uso como elemento de interworking entre tais tecnologias. Mais interessante ainda é o fato de o Cisco ASA poder ser incorporado a um tal cenário sem qualquer perda de funcionalidade.

Figura 2: Inserção do firewall em ambientes com H.323

A Figura 3 traz um cenário que envolve troca de sinalização sobre TLS (TCP 2443 para SCCP/TLS ou TCP/5061 para SIP/TLS) e posterior estabelecimento do canal SRTP através do firewall. Basicamente, o firewall se apresenta como CUCM para os telefones (usando os certificados apropriados) e simula ser um telefone para o CUCM. Após criação de tais relações de confiança, os telefones podem se registrar de forma segura e criar as sessões SRTP pertinentes.

Lembrando que as chaves para criptografia de voz são geradas durante o processo de sinalização, usar mensagens de controle em clear text não é uma abordagem conveniente. (Daí o fato de se recorrer ao transporte sobre TLS).

Figura 3: Criptografia de voz (SRTP) em ambientes com stateful firewalls

Para sintetizar o que foi exposto até aqui, achei interessante criar uma espécie de resumo sobre o que não pode faltar no seu firewall para telefonia, usando como exemplo o protocolo SIP (pois sua tendência de adoção é crescente):

• A partir da análise da sinalização SIP entre o controlador de chamadas IP (Call Manager)  e os telefones IP,  devem ser criadas dinamicamente as permissões pertinentes para o tráfego de mídia (RTP/RTCP) entre os telefones envolvidos.
• Deve ser possível configurar timeouts distintos para a conexão de sinalização SIP e para as conexões de mídia dinamicamente negociadas (RTP/RTCP).
•  A inspeção stateful da sinalização SIP deve estar igualmente disponível para TCP e UDP.
• O firewall deve ser capaz de analisar os pacotes de manutenção do canal de controle (keepalives) de modo a garantir que a conexão de sinalização não necessite ser restabelecida a cada chamada.
• Deve ser possível especificar os métodos SIP (SIP Methods) aceitáveis e bloquear requisições de conexão que utilizem métodos indesejáveis.
• Deve ser possível analisar conexões de sinalização criprografadas (SIP over TLS), de modo que sejam criadas dinamicamente as permissões adequadas para o tráfego de mídia cifrado (Secure RTP) entre os telefones IP envolvidos.

Para ir um pouco além do que foi tratado no presente post, sugiro a leitura do texto Firewalls and UC Security (artigo que escrevi para a Cisco Support Community): https://supportforums.cisco.com/docs/DOC-24159

** Leitura Adicional:

• Para obter mais detalhes sobre o tema (incluindo inúmeros exemplos reais de cenários de aplicação), veja o capítulo 13 do livro Cisco Firewalls:http://www.ciscopress.com/bookstore/product.asp?isbn=1587141094

NBAR - Dedo duro das Aplicações !

Ola  Pessoal,

Estou de volta estudando para CCNP SWITCH !

Nesse primeiro ponto irei falar sobre NBAR ( Dedo duro )

Vamos direto ao assunto...!

NBAR (Network Based Application Recognition) é um mecanismo criado pela Cisco pra, nada mais nada menos, que descobrir o tipo de tráfego (baseado nas portas layer 4) passando por uma interface especificada. E não somente portas conhecidas (<1024), como portas altas, por exemplo de programas P2P!

O objetivo é verificar o tipo de tráfego passando para depois serem aplicadas regras de QoS a fim de priorizar o tráfego que necessita mais prioridade, e limitando o tráfego "não interessante".

E tem mais, é bem simples de habilitar:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface FastEthernet 0/0
Router(config-if)#ip nbar protocol-discovery
Router(config-if)#

Pronto!

Agora para verificar:

show ip nbar resources -> podemos verificar o quanto de memória o NBAR está utilizando.
show ip nbar -> todo o tráfego passando pela interface.
show ip nbar protocol-discovery top-n -> verificar somente o tráfego das top "N" aplicações que estão utilizando os recursos (memória, cpu, etc) do roteador/MLS(Multi-Layer Switch).

A imagem abaixo nos mostra um exemplo do nbar habilitado em um roteador:



Pronto! Agora é só configurar o QoS :)

Abraços!!

Referência: http://slaptijack.com/networking/using-cisco-nbar-to-monitor-traffic-protocols-on-your-network/

Considerações sobre desempenho de Firewalls

Achei valido as informações de nosso amigo Alexandre M. S. P. Morais que trabalha na Cisco Brasil desde 1998 em projetos que envolvem Segurança e VPN, Design de Protocolos de Roteamento, Design de grandes redes LAN e Design de Redes MPLS. 

Certificações

• CCSP (Cisco Certified Security Professional)
• CISSP (Certified Information Systems Security Professional)
• CCIE #6063 (Routing & Switching, Security, Service Provider)

Autor do Livro

• Cisco Firewalls (Concepts, design and deployment for Cisco Stateful Firewall solutions) –  [Cisco Press, 2011]

Muitas das análises  se limitam a olhar o valor nominal de “throughput” (Gbps) e simplesmente ignoram aspectos vitais para o bom funcionamento de um Stateful Firewall . O presente texto é uma tentativa de revisitar tais parâmetros.

1. Novas conexões por segundo (Connections per second) – Há várias soluções no mercado que, apesar de apresentarem um número grande de throughput (Gbps), têm valor muito baixo para o parâmetro connections per second (CPS ). Para entender a importância deste parâmetro, basta lembrar que há várias verificações efetuadas pelo Firewall antes que o tráfego possa passar através do “backplane” dele.  Dentre elas, algumas merecem especial destaque:

• Análise de Fluxo:  o pacote que chegou `a interface de entrada é parte de um fluxo (conexão) existente ou é justamente o primeiro pacote e, portanto, uma nova conexão precisará ser criada ? Isto é particularmente importante para protocolos de aplicação que usam o TCP como transporte. (Basta lembrar das tarefas associadas ao “Three-way Handshake”…)
• O pacote que chegou é permitido pela ACL de entrada ?
• Existe regra de NAT que permita a passagem do tráfego ? (É sempre interessante questionar se os números de desempenho alegados por um fabricante levam em conta o uso de tal funcionalidade).
• Existe rota para encaminhar o pacote ?
• Existe regra de inspeção avançada (inspeção das instruções dentro do protocolo de aplicação)  para este fluxo  ?

Só após estas verificações o tráfego poderá usar o “backplane”.  A limitação do valor de CPS geralmente impede que o elemento chegue a usar o throughput (Gbps).

*Note que a atuação do Firewall é bem diferente de L2 Switching ( a análise deste é feita apenas buscando o MAC de destino numa tabela que associa o endereço L2 à uma porta física…)

** Muitos testes são feitos com pacotes UDP. O mais realista, no entanto, seria usar TCP, não só pelo fato de haver muito mais aplicações práticas que usam tal transporte mas também pelos aspectos de criação e manutenção de conexões (TCP é o transporte eminentemente Stateful, pois possui uma máquina de estados da qual constam Flags, números de seqüência e ACK, etc).

*** O atributo CPS ajuda a lidar com situações de acréscimo brusco de conexões (“flash flood”). Negar conexões por falta de CPS gera retransmissões e mais tráfego agregado de rede.

2. Pacotes por Segundo (pps) – Esta é a principal métrica para Roteadores e, considerando que os Stateful Firewalls (na maioria dos casos) se inserem na topologia como elementos L3, este parâmetro também não pode ser desprezado.

• Na visão de um Firewall Stateful, uma mesma conexão pode envolver muitos pacotes trafegados. (Pense, por exemplo, em uma transferência de um grande arquivo via FTP).
• O desempenho de algumas plataformas quando implementadas em ambientes com “pacotes pequenos”. Às vezes havia a impressão que os Firewalls em uso possuíam algum tipo de limitação no tratamento de tais pacotes. Na realidade, o que acontecia era o seguinte:  – os números de “Marketing” eram calculados com Jumbo Frames (~9000 bytes) e o resultado expresso em Gbps. Os números do ambiente real seguiam um perfil IMIX (~450 bytes). Como a expectativa de desempenho estava associada a Gbps, a decepção era grande… (desempenho 20 vezes menor do que o que constava no data sheet).

3. Conexões Simultâneas ( memória específica para manutenção da tabela de estados): corresponde ao número instantâneo máximo de entradas na tabela de conexões.

• A entrada é removida da tabela de estados após um tempo de inatividade (“idle timeout”).
• Este atributo está de certa forma relacionado com o número de CPS. Por quanto tempo o Firewall consegue absorver novas conexões (sem descartá-las) até o limite de conexões simultâneas ?

4. Throughput (Gigabits/segundo), um parâmetro associado à capacidade de encaminhamento.

Apesar de ser uma métrica muito importante para encaminhamento L2, no caso dos Stateful Firewalls este parâmetro acaba se tornando secundário. Diante do que já foi exposto, o valor de Gbps deveria ser uma conseqüência do número de Pacotes por Segundo (pps) suportado pelo equipamento e do conhecimento das características de tamanho de pacote do ambiente em que o Firewall será instalado.

Um artigo mais detalhado sobre o tema está disponível no seguinte link:

https://supportforums.cisco.com/docs/DOC-16954