Mostrando postagens com marcador Monitoramento. Mostrar todas as postagens
Mostrando postagens com marcador Monitoramento. Mostrar todas as postagens

terça-feira, 16 de dezembro de 2014

Gerenciamento e Monitoramento de Redes

Olá Pessoal.

Parte das tarefas do profissional de TI é a resolução de problemas técnicos na rede de computadores, ou seja, a correção de um problema assim que ele ocorre. Porém, como em outras situações, a prevenção é melhor do que a correção, por isso é importante monitorar o ambiente. Além disso, uma rede de grande porte não pode ser gerenciada unicamente pelo esforço humano e requer o uso de ferramentas automatizadas para fazer o monitoramento dos dispositivos da infraestrutura. 

Compartilho abaixo uma série recentemente produzida pelo NIC.br com vários vídeos didáticos sobre gerenciamento de redes, onde são abordados tópicos que contemplam desde boas práticas de gerenciamento, até ferramentas de monitoramento baseadas no protocolo SNMP.

Samuel.







quinta-feira, 9 de janeiro de 2014

Tradução de Guia Prático do Wireshark

Olá Pessoal

Nesta semana a Novatec Editora lançou a tradução de um livro em formato de guia prático que aborda o software Wireshark. A obra é intitulada "Wireshark Guia Prático - Análise e Resolução de Problemas de Tráfego de Rede" e possui 168 páginas dedicadas à operação dessa ferramenta.


A obra foi traduzida e lançada no Brasil pela Novatec Editora. Começa com uma introdução sobre a história e as funcionalidades do aplicativo, traz orientações sobre a sua instalação e configuração e oferece explicações essenciais sobre captura e navegação interativa pelo tráfego de rede de computadores.

O autor Robert Shimonski reuniu todas as informações necessárias para profissionais que efetuam testes de invasão (pen testers), hackers e administradores de rede desenvolverem habilidades práticas para aumentar a produtividade no uso do Wireshark.

A boa notícia é que em breve, assim que atingirmos 1500 CURTIR na fanpage do Blog LabCisco no Facebook (www.facebook.com/bloglabcisco) e encerrarmos a promoção vigente, teremos uma nova promoção e seu prêmio será um exemplar deste livro que foi gentilmente cedido pelos parceiros da Novatec. ;-)


Aqueles que ainda não conhecem o software Wireshark podem ter uma idéia da sua relevância na área de redes através da leitura de um artigo recentemente publicado por mim aqui no blog que é intitulado "Wireshark na Análise de Tráfego e Protocolos de Rede". Os interessados em comprar o livro podem fazê-lo pela página da Novatec Editora, acessando o link www.novatec.com.br/livros/wireshark.

Boa leitura...

Samuel.

domingo, 24 de novembro de 2013

Wireshark na Análise de Tráfego e Protocolos em Redes

Olá Pessoal.

Esse é mais um artigo que escrevi atendendo a pedido de leitores do blog e temos, dessa vez, como temática da discussão o software Wireshark, uma ferramenta extremamente poderosa que deve fazer parte do arsenal técnico de todo profissional da área de redes de computadores. O Wireshark é um analisador de pacotes que, para tanto, tem capacidade de interceptar "todos" os pacotes que trafegam nas redes e de exibir detalhes das suas informações de controle (cabeçalhos) e conteúdo (payload). O software é gratuito, está disponível para Linux/Windows e pode ser baixado no link http://www.wireshark.org, sendo que o guia do usuário pode ser baixado aqui.


É claro que em  um artigo é impossível esgotar todas as funcionalidades dessa ferramenta fantástica, por isso esse artigo tem três objetivos principais: (i) contextualizar a operação do software, (ii) delinear algumas características técnicas do arranjo topológico físico/lógico da rede que podem interferir no processo de captura dos pacotes a serem analisados e (iii) trazer dois exemplos de interpretação das saídas de pacotes capturados.

1) Operação do Software Wireshark

Um primeiro conceito importante que o leitor deve ter em mente antes de começar a operar esse software é que seu objetivo é trazer informações detalhadas sobre pacotes que foram previamente capturados em um ambiente em que exista uma rede de computadores. A ação de capturar/interceptar pacotes caracteriza uma atividade de escuta dos dados que trafegam na rede, por isso seu uso deve ser realizado por pessoal autorizado para fazê-lo no ambiente em operação, seja para simples monitoramento de conteúdo (a exemplo de conversas telefônicas via VoIP) ou mesmo para a identificação de problemas na rede para fins de otimização do seu desempenho. Esses são os propósitos do software e ele não deve ser utilizado sem autorização como sniffer de rede, o que caracteriza um ataque passivo de interceptação ao conteúdo da rede de computadores.

Normalmente há muito tráfego que chega nas interfaces de uma rede por meio de broadcast (ou outras tecnologias de transmissão) e que não são de interesse de uma interface específica, por isso o comportamento padrão é que somente o tráfego de interesse das interfaces é aceito, de forma que todos os demais pacotes são descartados. Esse é um comportamento padrão baseado na confiança que pode ser alterado através de um método que coloca as interfaces em modo promíscuo, um estado em que elas passam a receber e processar todos os pacotes entrantes/saintes.

O Wireshark organiza as informações de controle contidas nos cabeçalhos dos pacotes para facilitar o processo de leitura e análise técnica, no entanto é necessário que esses pacotes sejam previamente capturados em alguma interface de rede. Para fazê-lo o software utiliza bibliotecas que são responsáveis por colocar as interfaces de rede em modo promíscuo.

2) Características Técnicas do Arranjo Topológico da Rede

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 entredois 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. 

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. Paraestabelecer 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 1 e 2 de um switch não será transmitida na porta 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). Essa discussão sobre port-mirroring já foi apresentada em outro artigo do blog intitulado "Configuração de Espelhamento de Portas em Switch", onde o leitor pode encontrar exemplos de configuração baseados em tecnologias Cisco.

3) Interpretação de Pacotes Capturados

Uma vez apresentados ao leitor os principais conceitos relacionados ao Wireshark, essa última parte do artigo tem por objetivo trazer dois exemplos de como as saídas geradas pelo software podem ser interpretadas para mostrar o que acontece nos "bastidores" de uma rede de computadores. Para fazê-lo estarei utilizando dois exemplos clássicos com vocês, ambos baseados no processo de resolução de endereços MAC do IPv4 (através do ARP) e do IPv6 (através do NDP/ICMPv6).

O procedimento para verificar a descoberta do endereço físico (MAC) de uma interface de rede é bastante simples com o uso do Wireshark. Uma vez que a ferramenta faz a captura dos pacotes das redes, bem como a ordenação dos mesmos por categoria de protocolos, fica fácil identificar toda a comunicação oriunda dos protocolos ARP (no IPv4) e NDP (no IPv6).

Através das opções "Capture | Interfaces | Start" do Wireshark é possível iniciar a captura dos pacotes que estão trafegando na rede. O software irá organizar a saída da maneira apresentada nas figuras abaixo. Observem que a parte superior da tela traz várias linhas (entradas) que representam pacotes individuais e na parte inferior existe o detalhamento das informações dos cabeçalhos e payload desses pacotes, dispostos em conformidade com as camadas do TCP/IP. Quando o usuário clica em qualquer uma das linhas/entradas da parte superior, então a tela inferior muda seu detalhamento.

3.1 Protocolo ARP na Resolução de Endereços IPv4 em MAC

Aqui cabe uma revisão relâmpago acerca do ARP e do processo de resolução de endereços físicos no contexto do IPv4. Quando uma máquina quer se comunicar com outra ela conhece, a princípio, apenas o endereço lógico (IP) do destino, no entanto é necessário saber seu endereço físico (MAC) para que as interfaces de rede possam se comunicar na camada de enlace (tecnologia de rede).

Os sistemas operacionais armazenam uma tabela com as associações entre endereços MAC e IP (chamada Tabela ARP) e quando não existe uma correspondência nessa tabela, então o protocolo ARP (Address Resolution Protocol) entra em ação, conforme pode ser observado na figura abaixo. Na primeira comunicação para um dado destino, a máquina envia uma mensagem de broadcast para toda a rede local perguntando qual é o endereço físico da máquina que possui um determinado IP. Todas as máquinas da rede irão receber e processar essa requisição, no entanto somente a máquina que possuir o endereço IP procurado irá responder com a informação do seu endereço físico.


Por exemplo, nas próximas duas figuras, extraídas do Wireshark, o leitor pode observar que as linhas destacadas são pacotes do protocolo ARP (request e reply), onde faço alguns destaques importantes que mostram ao leitor como interpretar essas informações para compreender a operação do protocolo. Aproveitem essa oportunidade para fazer sua análise das figuras abaixo, comparando as informações trazidas pelo software com a explicação anterior. Veja que as informações procedem, por isso o Wireshark é um software importante também para convencer os alunos e facilitar o entendimento dos protocolos que operam nas redes de computadores.



3.2 Protocolo NDP na Resolução de Endereços IPv6 em MAC

Uma mudança significativa da operação do IPv6 diz respeito ao processo de resolução dos endereços físicos, já que não existe o protocolo ARP no IPv6. No IPv6 a funcionalidade de resolução de endereços lógicos em endereços físicos é responsabilidade do NDP (Neighbor Discovery Protocol), por meio de mensagens ICMPv6 Tipo 135 NS (Neighbor Solicitation) e ICMPv6 Tipo 136 NA (Neighbor Advertisement). Cabe aos sistemas operacionais manterem uma tabela de vizinhança com as associações entre os endreços IPv6 <> MAC.


Com base na figura acima, quando o Host-A deseja se comunicar com o Host-B (2001:db8:cafe:1::1), ele envia uma mensagem a um "grupo" de máquinas para descobrir o endereço MAC da interface configurada com esse IPv6. Para tanto, a mensagem é destinada ao endereço multicast-solicited-node respectivo que, nesse exemplo, é o endereço ff02::1:ff00:1. O formato do endereço solicited-node é ff02::1:ffXX:XXXX, onde X representa os últimos 24 bits do IPv6 do destino.

O campo target do cabeçalho é preenchido com o endereço IPv6 a ser resolvido, o que evita a ambiguidade em caso de duas ou mais máquinas terem os mesmos 24 bits finais no seu endereço. Além disso, existe um campo de opções chamado source-link-layer-address, que é preenchido com o endereço MAC da origem para evitar que o destino, ao receber a mensagem, tenha que refazer esse processo de resolução de endereços para obter o MAC do vizinho antes de respondê-lo.


Na segunda etapa, assim que recebe uma NS com seu endereço IPv6 no campo target, o Host-B envia uma mensagem NA com o seu endereço MAC no campo target-link-layer-address (00:00:00:00:AA:00), destinado unicamente ao Host-A (origem da NS anterior). Quando a mensagem NA chega ao Host-A, já é capaz de criar uma nova associação na sua tabela de vizinhança e, portanto, aprendeu o endereço MAC 00:00:00:AA:00 do IPv6 2001:db8:cafe:1::1.


Caso o leitor tenha dúvidas a respeito do modus operandi do IPv6, recomendo a leitura do meu livro intitulado "IPv6 - O Novo Protocolo da Internet". As explicações trazidas nesse artigo tinham por objetivo subsidiar o entendimento de como interpretar as saídas do Wireshark, por isso não houve aprofundamento teórico.

Abraço.

Samuel.

sábado, 4 de maio de 2013

Interpretação dos Resultados do Ping

Olá Pessoal.

Esse é mais um artigo que escrevo atendendo a pedido dos leitores do blog. Existem várias ferramentas de monitoramento de redes no mercado, sendo que todas elas, de alguma forma, retornam algumas métricas importantes de desempenho em redes, tais como: vazão em bps, latência (atraso), jitter (variação da latência no tempo), etc. A mais comum de todas essas ferramentas e que certamente faz parte da vida cotidiana de TODO profissional de redes é o "bom e velho" ping - presente em praticamente todas as caixas e sistemas operacionais!

Apesar de parecer simples, o ping vai MUITO além de simplesmente confirmar se há comunicação com um host remoto qualquer - ele também traz alguns valores importantes para determinar o desempenho de uma rede. Para cada linha de resposta echo-reply do ICMP (protocolo utilizado por trás do ping) ele traz o valor do atraso fim-a-fim na comunicação (latência), conforme pode ser observado no primeiro destaque em vermelho da figura abaixo.

Também ao final da sequência de respostas ele traz um resumo estatístico com os valores mais baixo, médio e alto da latência nos parâmetros rtt min/avg/max. Ele ainda mostra qual foi a porcentagem de perda de pacotes que, normalmente, não deve exceder 2%. Valores de perda de pacotes acima de 5% são indicativos de que está havendo algum problema na rede, que pode ser desde o cabeamento até a aplicação em si! É importante destacar que no Linux ele calcula o jitter (parâmetro denominado mdev no ping). Essas informações podem ser observadas no segundo destaque em vermelho da figura abaixo.


Não existe um valor único de latência que seja referência para todas as redes, por isso estarei mostrando alguns valores referenciais aceitáveis para algumas das tecnologias mais comuns que são: (1) Rede Local, (2) Internet via TV a Cabo, (3) xDSL, (4) Dial-Up e (5) Links de Longa Distância Privativo.

1) Em redes locais cabeadas a comunicação deve ter excelente desempenho, haja vista a proximidade entre os dispositivos e a boa qualidade da infraestrutura de cabeamento de propriedade da empresa. É esperado que a latência em redes locais não ultrapasse 10ms (recomendado) ou é tolerável até 30ms (não recomendado). Quanto mais dispositivos intermediários existirem entre duas máquinas, naturalmente maior será essa latência porque cada dispositivo intermediário terá algum mecanismos de tratamento dos quadros;

2) Um valor ideal de latência para links de Internet via Cable Modem seria algo entre 30ms e 50ms. No entanto a arquitetura da rede é compartilhada através de barramentos nas vizinhanças e a rede tende a sofrer mais com instabilidade em momentos de muito acesso, o que pode implicar em latências maiores que 100ms; 

3) A latência ideal para a tecnologia xDSL seria algo em torno de 70ms. O que acontece é que essa tecnologia é muito popular porque aproveita a infraestrutura de cabeamento da rede telefônica, motivo pelo qual muitas operadoras acabam vendendo mais conexões do que suas centrais suportam. Essa situação pode implicar em latências de 100ms ou mais, o que é comum de acontecer no Brasil;

4) A conexão discada naturalmente é aquela que apresenta pior desempenho porque utiliza a rede pública de telefonia comutada (PSTN) através da modulação do sinal digital do computador em sinal analógico (audio), ou seja, simplificando, conversão dos dados em som. Por isso a latência dessa tecnologia pode facilmente ser bem superior a 250ms;

5) Os links de longa distância privativos mais profissionais, ou seja, aqueles normalmente utilizados pelas empresas devem apresentar excelente desempenho. Normalmente os contratos desses links têm cláusulas de SLA em que a operadora se compromete a entregar uma qualidade mínima com base em parêmetos pré-definidos. Normalmente esses links também não devem exceder 10ms (recomendado), mas pode ser tolerável latência de até 20ms ou 30ms (dependendo do contrato); 

Lembrem-se de que essas informações são referenciais, ou seja, nenhum desses valores deve ser aceito como REGRA! Há outros fatores que vão interferir diretamente na latência, principalmente quando pensamos em links de longa distância. Por exemplo, em situação ideal o sinal percorre um cabo metálico a aproximados 200.000 km/s (quase 2/3 da velocidade da luz). Isso quer dizer que você terá resultados diferentes na sua empresa se pingar um servidor localizado no Brasil e outro na China! ;-) Por isso antes de verificar o desempenho da rede é necessário estabelecer os critérios que serão utilizados para fazê-lo, criando uma metodologia homogênea que não interfira nos resultados!

Outro detalhe importante é que vejo as pessoas testando a velocidade da conexão de Internet em casa e sempre muito preocupadas com a tal largura de banda ou taxa de transmissão (em bps), no entanto tão importante quanto a largura de banda é a latência. Por exemplo, vamos pensar na seguinte situação:

Cenário 1: Ana contratou uma Internet xDSL de 25M
- Teste de Desempenho: Taxa de Transmissão de 19M; Latência de 190ms;

Cenário 2: Beto contratou Internet Cable de 10M
- Teste de Desempenho: Taxa de Transmissão de 8M; Latência de 60ms;

Na sua opinião qual dos dois cenários é melhor?
A resposta correta é: Cenário 2

Acontece que mesmo a Ana tendo mais largura de banda para acessar mais informação, o estado do link está MUITO pior do que o do Beto que possui menos da metade da largura de banda. No entanto, o retorno das requisições de Beto será muito mais rápido do que da Ana. É isso que explica porque um link de 2M na empresa em que você trabalha tende a ter desempenho muito melhor do que a Internet de 10M da sua casa!!! As latências dos links de longa distância privativos são muito menores do que as latências das conexões residencias!  

Compreenderam? Espero que sim... 

O jitter, por exemplo, é uma métrica extremamente importante para ambientes que possuem aplicações multimídia de "tempo real", como voz e vídeo. Os administradores de ambientes que possuem essas aplicações devem sempre estar atentos não somente à latência que representa o atraso na entrega dos pacotes, mas principalmente ao jitter. A latência mostra o desempenho real da rede naquele exato momento, enquanto que o jitter mostra seu comportamento ao longo do tempo, ou seja, define o grau de estabilidade da rede.

Pegando o exemplo do ping da figura acima que apresenta jitter de 15ms, esse seria um valor alto para uma rede local cabeada (ethernet), mas é um valor comum em redes sem fio pela própria natureza mutável do ambiente. Lembrem-se que as comunicações sem fio estão sujeitas a interferência de vários fatores externos, por isso o sinal tende a oscilar com maior frequência - o que as faz mais instáveis do que as redes cabeadas.

Uma evidência prática de que o jitter é ainda mais prejudicial para aplicações multimídia do que a própria latência é que normalmente o recurso comumente utilizado para minimizar o efeito do jitter consiste na utilização de buffers (pequenas memórias eletrônicas) nos dispositivos para armazenar os pacotes e, somente então, entregá-los "sem" jitter ao usuário, conforme pode ser observado na figura abaixo.


O problema é que essa "solução" implica no aumento da latência, o que mostra a preferência pelo aumento na latência se houver diminuição do jitter. Obviamente que o alinhamento dessas duas métricas (latência e jitter) acaba sendo um exercício de balança e o bom senso é fundamental para assegurar o bom desempenho das aplicações. De nada adianta eliminar totalmente o jitter se a latência ficar muito alta. O valor ideal do jitter vai variar em função da latência do link.

Por exemplo, no contexto de um link de longa distância xDSL (acesso à Internet) que tem em média de 50ms a 100ms, um jitter de até 15ms ou 30ms pode ser aceitável. Por outro lado, no contexto de uma rede local em que a latência máxima é 10ms, esses valores seriam inaceitáveis - principalmente se existirem aplicações multimídia de "tempo real".

A gente costuma utilizar como medidas de referência para latência em aplicações multimídia o limite de até 150ms para bom desempenho (recomendado) e valores entre 151ms até 400ms para desempenho tolerável (não recomendado), sendo que qualquer valor acima de 400ms é INACEITÁVEL!!!


Quem diria que uma ferramenta tão simples quanto o ping seria na realidade tão poderosa, não é mesmo? ;-) Esse é um dos motivos de eu sempre dizer aos meus alunos que na área de networking é crucial entrender os fundamentos por trás da tencologias, muito mais até do que saber operacionalizar. O ideal é "casar" as duas coisas: fundamento e prática!

Espero que esse artigo seja útil não apenas no dia-a-dia de vocês, mas principalmente no sentido de "abrir a mente" para a necessidade do profissional dessa área conhecer os fundamentos daquilo que está operacionalizando!

Abraço.

Samuel.

sexta-feira, 26 de abril de 2013

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.