Espelhamento de Portas em Switches Remotos (RSPAN)

Olá Pessoal.

No artigo anterior intitulado "Configuração de Espelhamento de Portas em Switch" foi explicado o conceito por trás do recurso SPAN (Switched Port Analyzer) com os passos necessários para configurá-lo,  já que esse é um recurso útil no monitoramento do tráfego da rede através do espelhamento de portas na linha Catalyst de Switches da Cisco.

Alguns leitores do blog interessados no assunto me pediram para escrever um artigo sobre o recurso RSPAN (Remote Switched Port Analyzer) que permite ampliar esse monitoramento em redes maiores através da criação de sessões de monitoramento com o destino do tráfego espelhado em algum outro switch remoto.

Para exemplificar como seria o processo de configuração do RSPAN estaremos considerando o cenário abaixo em que agora existem dois switches interligados através de um entroncamento (trunk), diferente do cenário do artigo anterior que havia um único switch. Vamos supor que a máquina na interface f0/2 quer se comunicar com a outra máquina e para tal enviou um quadro destinado a f0/1. Reparem que o quadro por ela originado é espelhado através da rede até chegar na interface f0/7 do switch remoto onde está "pendurado" o monitorador!

No SPAN tradicional (um único switch) você informava uma fonte (interfaces ou VLAN) e uma porta de destino onde os quadros espelhados eram entregues. No RSPAN o processo é um pouco diferente, já que envolve mais de um switch. Da mesma forma continua sendo necessário informar a(s) fonte(s) que podem ser interfaces (seja de acesso, trunk ou mesmo uma agregação lógica port-channel) ou uma VLAN. A diferença é que agora o destino será uma VLAN RSPAN por onde os quadros espelhados irão trafegar através da rede até chegarem no switch remoto que irá direcioná-los para a porta de destino!

 

Portanto, considerando o cenário da figura anterior, agora temos dois switches para configurar, o SW1 com as interfaces f0/1 e f0/2 de origem em que ocorrerá o espelhamento dos quadros e o SW2 com a interface f0/7 de destino onde o tráfego será entregue. Naturalmente que é necessário que entre os dois switches exista um canal de comunicação através da VLAN do RSPAN - a VLAN 33 nesse exemplo. Vamos às configurações:

01. SW1(config)# vlan 33

02. SW1(config-vlan)# name VLAN-RSPAN

03. SW1(config-vlan)# remote span

04. SW1(config-vlan)# exit

05. SW1(config)# interface g0/1

06. SW1(config-if)# switchport mode trunk 

07. SW1(config-if)# exit  

09. SW1(config)# monitor session 1 interface f0/1

10. SW1(config)# monitor session 1 interface f0/2

11. SW1(config)# monitor session 1 destination remote vlan 33     

Primeiro foi criada a VLAN 33 que já recebeu a instrução de que será utilizada para fins de transporte dos quadros espelhados pelo RSPAN. Na sequência configuramos a interface g0/1 em modo de entroncamento (trunk), ou seja, ela será capaz de transportar tráfego de todas as VLANs que existirem entre os switches, inclusive a VLAN RSPAN (33). Por fim foram informadas as interfaces de origem e reparem que agora o destino do espelhamento será a VLAN remota previamente criada.

01. SW2(config)# vlan 33
02. SW2(config-vlan)# name VLAN-RSPAN
03. SW2(config-vlan)# remote span
04. SW2(config-vlan)# exit
05. SW2(config)# interface g0/1
06. SW2(config-if)# switchport mode trunk
07. SW2(config-if)# exit
08. SW2(config)# monitor session 1 source remote vlan 33
09. SW2(config)# monitor session 1 destination interface f0/7 

As primeiras linhas (de 1 a 7) são idênticas e fazem exatamente a mesma coisa. A diferença é que no SW2 informamos a VLAN RSPAN (33) como origem e já configuramos qual será a interface de destino do tráfego espelhado. É só isso...
 

Abraço.

Samuel.

Configuração de Espelhamento de Portas em Switch

Olá Pessoal.

Um recurso muito útil para fins de monitoramento na linha Catalyst de Switches da Cisco® é denominado SPAN, acrônimo de Switched Port Analyzer. Esse recurso também é chamado de port-mirroring (espelhamento de porta) ou port-monitoring (monitoramento de porta).

Logo nas primeiras aulas de redes de computadores os alunos estudam conceitualmente os principais dispositivos de interconexão onde são apresentadas as principais diferenças entre dois dispositivos concentradores: (i) HUB e (ii) Switch.

Nessa ocasião os alunos aprendem que mesmo ambos os dispositivos sendo elementos centrais (concentradores) que criam uma topologia física de estrela, o modo de operação entre eles é distinto implicando em diferentes topologias lógicas, conforme pode ser observado na figura abaixo.

O HUB cria uma topologia lógica de barramento porque eletronicamente todas as suas portas estão ligadas em um mesmo barramento físico, o que implica na existência de um único dominío de colisão compartilhado entre todas as portas. Ele é um simples dispositivo repetidor que (i) recebe sinal em uma porta de entrada, (ii) amplifica esse sinal e (iii) despacha esse sinal para todas as demais portas de saída. Como ele é um dispositivo de camada física, não possui inteligência para analisar os cabeçalhos dos quadros.

Uma vez que a topologia lógica do HUB é de barramento, o sinal recebido em uma porta é retransmitido para TODAS as demais portas, o que é ruim do ponto de vista de desempenho e segurança. Por causa disso é muito simples interceptar o tráfego/conteúdo dessa rede através de algum software sniffer, já que todo sinal entre quaisquer máquinas é propagado para todas as portas. O Wireshark é um exemplo de software gratuito de interceptação de pacotes (analisador de protocolos) e pode ser baixado no link http://www.wireshark.org/.

Por outro lado o Switch cria uma topologia lógica de estrela porque eletronicamente possui uma matriz (denominada matriz crossbar) que permite o chaveamento de circuitos ponto-a-ponto entre duas portas específicas, o que implica em um domínio de colisão para cada porta. Para estabelecer esses circuitos entre duas portas os switches são dispositivos da camada de enlace e possuem inteligência para analisar os cabeçalhos dos quadros, motivo pelo qual eles utilizam o endereço físíco das interfaces (MAC) no processo de encaminhamento.

É comum o uso de softwares de interceptação de quadros/pacotes em redes de computadores para fins de monitoramento e análise da "saúde" da rede. O problema de utilizar esses softwares nas redes que possuem switch (diga-se de passagem quase todas atualmente), é que ao conectar o computador monitorador em uma porta qualquer do switch ele não será capaz de "escutar" nenhum tráfego entre os circuitos fechados nas demais portas. Por exemplo, uma comunicação entre dois computadores ligados nas portas f0/1 e f0/02 de um switch não será transmitida na porta f0/3 (nem em qualquer outra).

É para resolver esse problema que existem as tecnologias de port-mirroring. Essa tecnologia de espelhamento consiste em configurar uma determinada porta do switch para espelhar todo o tráfego entre os circuitos das demais portas, daí no nome espelhamento. Ou seja, essa porta irá se tornar o "dedo-duro" da rede replicando todo o tráfego como se fosse um HUB. Naturalmente essa porta será aquela em que o computador monitorador estará executando o software de interceptação (sniffer).

Vamos considerar o cenário ilustrado na figura abaixo para exemplificar o processo de configuração do SPAN nos seguintes modelos de Switch Catalyst da Cisco: 2940, 2950, 2955, 2960, 2970, 3550, 3560, 3560-E, 3750 e 3750-E. Em outros modelos de switches os comandos para configuração do SPAN podem ser diferentes! 

Reparem que temos uma rede local em que existe um notebook conectado na interface f0/7 do switch e que estará executando um software de interceptação, como por exemplo o Wireshark. Ao fazê-lo a interface de rede do notebook é colocada em modo promíscuo, ou seja, ela passará a capturar todo tráfego escutado por ela, seja ele direcionado a ela ou não. Caberá ao switch a função de replicar (espelhar) todos os quadros das demais portas para a interface f0/7. 

No exemplo seguinte vamos configurar a interface f0/7 como a porta de destino do monitorador e optaremos pelo espelhamento do tráfego apenas das interfaces f0/1 e f0/2 (origem). Para esse cenário a configuração do switch seria a seguinte:

Switch# configure terminal
Switch(config)# monitor session 1 source interface f0/1
Switch(config)# monitor session 1 source interface f0/2
Switch(config)# monitor session 1 destination interface f0/7 
Switch(config)# exit
Switch# show monitor session

Ao invés de informar as interfaces de origem manualmente, também é possível monitorar toda uma VLAN previamente configurada no switch. Nesse caso seria informada apenas a VLAN como origem e todas as interfaces associadas à respectiva VLAN teriam  seu tráfego automaticamente espelhado para a porta de destino SPAN. À medida que portas são removidas ou associadas com a VLAN, então seu tráfego já será espelhado. Não é possível combinar o espelhamento de interfaces e VLANs! Vamos supor que as interfaces f0/1 e f0/2 do exemplo anterior estivessem associadas com a VLAN-13, a configuração seria:

Switch(config)# monitor session 1 source vlan 13

Switch(config)# monitor session 1 destination interface f0/7

Existe ainda a possibilidade de ampliar o monitoramento em redes maiores criando sessões de monitoramento com o destino do tráfego espelhado em algum outro switch remoto através do recurso RSPAN (Remote Switched Port Analyzer). Se vocês tiverem interesse nessa tecnologia, me avisem que escreverei outro artigo para exemplificar sua configuração.

Abraço.

Samuel.

IPERF no Monitoramento de Desempenho em Redes

Olá Pessoal.

O IOS da Cisco traz algumas ferramentas bem úteis para medir o desempenho de dispositivos de interconexão em infraestrutura de redes (switches, roteadores, etc), a exemplo do SLA-Monitor e do NetFlow. É igualmente importante a tarefa de monitoramento e avaliação do desempenho dos links das estações até os servidores da rede, para garantir que a vazão dimensionada para fins de acesso aos recursos dos servidores esteja realmente adequada.

É nesse contexto que uma ferramenta muito útil denominada Iperf se destaca pela sua simplicidade e principalmente por ser gratuita. O Iperf é um software livre que foi desenvolvido pelo National Laboratory for Applied Network Research (NLANR). Ele foi originalmente desenvolvido para fins de pesquisa com o intuito de testar a largura de banda (throughput) em links, ou seja, medir o desempenho de redes de computadores. O software não possui interface gráfica, sendo sua operação muito simples através da linha de comando. Também existe uma versão do Iperf em Java, denominada Jperf, que possui interface gráfica e que gera gráficos a partir das medidas realizadas. 

Em síntese a operação do Iperf se resume à sua execução entre duas máquinas, uma em modo servidor que ficará "ouvindo" as requisições e outra em modo cliente que ficará responsável por gerar tráfego para estressar a rede e extrair as medidas de desempenho.

Para exemplificar o uso dessa ferramenta vamos considerar o cenário ilustrado na figura abaixo que é bem simples e suficiente para a demonstração. Iremos executar o software em modo servidor na máquina File-Server (Windows Server 2008) para posteriormente executarmos o software em modo cliente em qualquer máquina, por exemplo um notebook executando Linux para fins de análise de desempenho. 

O leitor pode baixar o Iperf para Linux e Windows através da página oficial do projeto em http://sourceforge.net/projects/iperf/. A ferramenta é multiplataforma e o teste funciona normalmente entre estações Linux-Linux, Windows-Linux ou Windows-Windows. Para executar o software em modo servidor, basta digitar o seguinte comando:  

iperf -s

A partir desse momento a máquina estará ouvindo requisições TCP na porta 5001, onde o cliente posteriormente irá gerar tráfego para estressar o enlace entre cliente-servidor. Feito isso, a partir de outra máquina qualquer na rede que tenha alcançabilidade IP ao servidor, seja no contexto da mesma rede local ou mesmo atrás de roteadores, podemos executar o software em modo cliente com o seguinte comando: 

iperf -c 192.168.7.3

Por padrão o cliente irá gerar tráfego TCP na porta 5001 do servidor (192.168.7.3) durante 10 segundos. Reparem que no exemplo da figura abaixo utilizei alguns parâmetros opcionais para alterar o tempo padrão (de 10s para 15s) e também o intervalo de geração dos relatórios para registrar as medidas a cada 1s. Há vários outros parâmetros que você pode (e deve) explorar, então trago um resumo das principais opções: 

- s -> Execução em modo servidor na porta 5001

- c -> Execução em modo cliente, sendo necessário informar o IP do servidor
- b -> Define a banda a ser utilizada em bps (apenas para UDP)

- d -> Gera tráfego nos dois sentidos (por padrão o tráfego é sentido cliente->servidor)

- u -> Utiliza o UDP como protocolo de transporte

- f -> Define a unidade do relatório, que pode ser: Kbits, Mbits, KBytes, MBytes

- i -> Define o intervalo de tempo de registro do relatório de saída

- m -> Exibe na saía o tamanho máximo do MTU
- o -> Armazena a saída em arquivo externo, ex.: -o <nome-do-arquivo>
- p -> Altera a porta padrão de execução, ex.: iperf -s -p 2222
- P -> Somente em modo cliente, gera tráfego simulando vários clientes em paralelo
- t -> Define o tempo de duração dos testes, sendo o padrão 10 segundos  

No exemplo da figura anterior (que representa a saída do software cliente) a gente pode observar que durante o teste a largura de banda apresentou uma variação média entre 9Mbps e 15Mbps, cujo PÉSSIMO resultado é um indicativo de problema se o link entre o cliente e o servidor for de 100 Mbps ou 1 Gbps. 

No projeto de uma rede você sempre deve ter em mente que a vazão dos servidores deve ser suficientemente maior que a vazão das estações para que os recursos dos servidores possam ser simultaneamente utilizados por várias estações. Resultados ruins no teste com essa ferramenta podem demonstrar que o link do servidor está subdimensionado nos horários de pico em que existem múltiplas máquinas querendo acessar os recursos do servidor.

Outra opção muito útil é realizar a medição anterior utilizando o UDP como protocolo de tranpsorte. O interessante de fazê-lo é que também será medido o jitter do enlace, ou seja, a variação entre os tempos de latência fim-a-fim (atraso) na comunicação - uma importante métrica de desempenho para verificar a estabilidade (ou instabilidade) da rede.

Para realizar a medição via UDP, basta adicionar o parâmetro "-u"  no servidor (iperf -s -u) e cliente (iperf -c 192.168.0.1 -u). Há outros parâmetros e caso vocês queiram conhecer mais detalhes da ferramenta, recomendo a leitura da documentação técnica disponibilizada na página oficial do projeto. Espero que esse artigo seja útil no dia-a-dia de vocês, usem e abusem da ferramenta.

Abraço.

Samuel.

Falha na Atualização KB2823324 da Microsoft

Olá Pessoal.

FIQUEM ATENTOS: Aqueles que são usuários do Windows 7 PT-Br (32 Bits), DESATIVEM temporariamente as atualizações de segurança do Windows Update. Na terça-feira (09/04) a Microsoft lançou a atualização KB2823324 que compromete o funcionamento do sistema. Todas as empresas que possuem um servidor WSUS devem REPROVAR essa atualização!!!

Apesar do blog ser focado em dispositivos de interconexão em infraestrutura de redes, essa notícia é de interesse coletivo de todos os profissionais de Tecnologia da Informação - somente agora consegui escrever uma nota sobre o assunto. Vocês podem encontrar mais informações sobre essa notícia no link abaixo:

http://idgnow.uol.com.br/ti-corporativa/2013/04/10/falha-em-atualizacao-do-windows-7-impede-inicializacao-do-sistema/

Esse foi um erro grave que deverá custar caro para a reputação da Microsoft no cenário nacional, tanto para os usuários residenciais como para os clientes corporativos! Até o momento a Microsoft se pronunciou pedindo desculpas aos seus clientes pelo transtorno e dizendo que está trabalhando na solução do problema, no entanto ainda não foi lançada nenhuma nota oficial pela empresa tratando do assunto.

Abraço.

Samuel.