Servidores DHCPv6 em Redes IPv6

Olá Pessoal.

Muito se fala da visível diferença que existe nos endereços IPv4 (32 Bits) e IPv6 (128 Bits), o que permite uma quantidade de endereços de ordem astronômica com o "novo" protocolo - 340 undecilhões de endereços possíveis! Porém, pouco se fala das VÁRIAS outras diferenças que existem entre os protocolos. O IPv6 é um protocolo novo e que, portanto, possui muitas particularidades bem diferentes do seu antecessor - o tradicional IPv4.

Por exemplo, quando pensamos na questão da atribuição dos endereços, o "novo" IPv6 permite que essa configuração seja realizada de diversas maneiras, tais como:

• Autoconfiguração Stateless (SLAAC)

• Configuração Estática

• Configuração Estática EUI-64

• DHCPv6 Stateful

• DHCPv6 Stateless

Seria necessário um artigo para cada uma dessas técnicas, então esse artigo será focado apenas nas principais diferenças entre o DHCPv6 nas modalidades: (i) Stateful e (ii) Stateless. Aproveitarei a oportunidade para mostrar as diferenças na configuração de um serviço DHCP em roteadores Cisco para ambientes IPv4 e IPv6.

No IPv4 o tradicional serviço de DHCP (Dynamic Host Configuration Protocol) é definido na RFC 2131 e diz respeito à distribuição automática de endereços em uma rede TCP/IPv4 através de um servidor reponsável por executar uma instância de um serviço DHCP. É nesse servidor em que o administrador irá criar um escopo definindo o intervalo de endereços que será distribuído para as máquinas, bem como outras configurações importantes: gateway da rede, servidores de resolução de nomes (DNS), opções, etc.

Nesse caso cabe ao servidor manter uma tabela com o registro dos clientes, seus respectivos endereços atribuídos e seu tempo de empréstimo (lease). Uma vez que o servidor é responsável por manter essa tabela com o "estado" dos clientes associando os endereços físicos das máquinas (MAC) com os endereços lógicos atribuídos (IP), então dizemos que esse é um serviço de natureza stateful, ou seja, é mantido um registro de informações.

A sua configuração através de um roteador Cisco é bastante simples, bastando a entrada de alguns poucos comandos para fazê-lo. Vamos observar o cenário da figura abaixo em que temos uma rede 192.168.221.0 /24, sendo que todas as máquinas estarão configuradas para obter o endereço dinamicamente e o roteador será responsável por executar o serviço DHCP. As configurações necessárias seriam as seguintes:

01. Router(config)# ip dhcp excluded-address 192.168.221.1 192.168.221.30

02. Router(config)# ip dhcp pool NOME-ESCOPO

03. Router(config-dhcp)# network 192.168.221.0 255.255.255.0

04. Router(config-dhcp)# default-router 192.168.221.1

05. Router(config-dhcp)# dns-server 192.168.221.2

Na primeira linha definimos quais endereços devem ser excluídos do escopo que será posteriormente criado, uma vez que esses endereços serão atribuídos estaticamente porque são reservados para os servidores. Na segunda linha foi dado um nome para o escopo que irá compreender os endereços da rede informada na terceira linha, sendo que nas linhas 4 e 5 são informados os endereços que as máquinas deverão utilizar como gateway e DNS. Pois bem, até aqui bem simples! 

Acontece que quando pensamos em IPv6 as coisas mudam bastante. Primeiro porque nativamente as redes IPv6 têm suporte ao processo de autoconfiguração stateless em que as próprias máquinas são capazes de formar seu endereço através de duas etapas: (i) a máquina determina seu identificador de host (sufixo) a partir do endereço físico da interface (MAC) e (ii) a máquina determina seu identificador de rede (prefixo) através de anúncios emitidos pelo roteador através de um protocolo de descoberta de vizinhança (NDP). Em um próximo artigo escreverei detalhadamente sobre o processo de autoconfiguração dos enredeços IPv6...

Por conta disso, via de regra, um servidor DHCP seria algo dispensável em redes IPv6 e agora o roteador da infraestrutura se torna um elemento ainda mais importante. Apesar disso, o DHCPv6 é definido na RFC 3315 e pode existir em duas modalidades: (i) stateful e (ii) stateless. 

A modalidade stateless é aquela em que o servidor não mantém um registro dos endereços atribuídos aos clientes porque agora as máquinas irão formar automaticamente seu endereço a partir do endereço físico da interface de rede (MAC) e através dos anúncios dos prefixos dos roteadores. Nessa modalidade cabe ao servidor DHCPv6 informar apenas os endereços complementares, tais como: DNS e/ou Opções. Vale destacar que a funcionalidade stateless é muito útil para informar automaticamente os servidores DNS da rede, afinal em IPv6 o serviço DNS é fundamental para amenizar a "complexidade" do endereço de 128 bits.

Estamos falando de uma versão bastante simplificada do DHCP que não consome muitos recursos do "servidor" e que utiliza como base o processo de autoconfiguração! Para exemplificar como seria a configuração desse serviço, vamos observar o cenário da figura abaixo que é apenas uma reprodução da figura anterior num ambiente TCP/IPv6 em que temos a rede 2001:DB8:CAFE::/64.

O processo de configuração do DHCPv6 Stateless consiste em criar e configurar o "escopo" (linhas de 1 a 3), destacando que é importante ativar o serviço DHCPv6 na interface conectada à LAN que receberá os endereços dinâmicos (linha 7) e informar aos hosts que as informações complementares devem ser aprendidas pelo serviço DHCPv6 (linha 8), através da ativação da flag O (other-config-flag).

01. Router(config)# ipv6 dhcp pool NOME-ESCOPO
02. Router(config-dhcp)# dns-server 2001:DB8:CAFE::2
03. Router(config-dhcp)# domain-name labcisco.com.br
03. Router(config-dhcp)# exit
04. Router(config)# int f0/0
05. Router(config-if)# ipv6 enable
06. Router(config-if)# ipv6 address 2001:DB8:CAFE::1/64
07. Router(config-if)# ipv6 dhcp server NOME-ESCOPO
08. Router(config-if)# ipv6 nd other-config-flag
09. Router(config-if)# end

Embora não seja recomendado pela Cisco e nem todos os roteadores suportem, ainda existe uma versão stateful do DHCPv6 para aqueles que precisam manter o registro dos endereços dinamicamente atribuídos e que querem determinar o escopo explicitamente. Normalmente essa modalidade será empregada em servidores Linux e Windows Server. O processo de configuração do DHCPv6 Stateful no roteador ficaria:

01. Router(config)# ipv6 dhcp pool NOME-ESCOPO
02. Router(config-dhcp)# address prefix 2001:DB8:CAFE::/64 lifetime 1800 60
03. Router(config-dhcp)# dns-server 2001:DB8:CAFE::2
04. Router(config-dhcp)# exit
05. Router(config)# int f0/0
06. Router(config-if)# ipv6 enable
07. Router(config-if)# ipv6 address 2001:DB8:CAFE::1/64
08. Router(config-if)# ipv6 dhcp server NOME-ESCOPO
09. Router(config-if)# ipv6 nd managed-config-flag
10. Router(config-if)# exit

Reparem que agora tivemos que configurar na interface (linha 9) uma opção que instrui os clientes a receber todas as configurações de endereço via DHCPv6 (stateful), procedimento feito através da ativação da flag M (managed-config-flag). Além disso, na linha 2 o prefixo é explicitamente configurado.

Por fim, o segiunte comando poderia ser utilizado para fins de verificação:

Router# show ipv6 dhcp pool

Esse artigo mostra que as diferenças entre os protocolos IPv4 e IPv6 estão muito além do formato do endereço utilizado. O IPv6 é um protocolo que possui muitas particularidades que não existiam no seu antecessor, motivo pelo qual precisamos disseminar suas funcionalidades e qualificar mais profissionais preparados para lidar com o novo protocolo.

Abraço.

Samuel.

IPv6 no Café da Manhã

Olá Pessoal.

Em 28 de maio, no período da manhã, estarei no NIC.br (Núcleo de Informação e Coordenação do Ponto BR) para participar como membro da mesa no evento "IPv6 no Café da Manhã" que será realizado na sede do NIC em São Paulo. Há 50 vagas para participação presencial, sendo que o evento também será transmitido via Internet. Os interessados podem obter maiores detalhes sobre as inscrições presenciais ou sobre a transmissão online através do link oficial da notícia em: http://ipv6.br/cafe/

Na oportunidade do evento representantes de várias universidades estarão compondo uma mesa para compartilhar experiências, casos de sucesso e dificuldades em relação ao novo protocolo da Internet. O NIC.br me convidou para falar sobre o processo de inclusão do IPv6 na matriz curricular dos cursos de Graduação e Pós-Graduação em Redes de Computadores da UNIMEP, bem como sua adequação às recomendações internacionais do IPv6 Forum no processo de obtenção da ceritificação dos cursos da universidade.

Obs.: Para quem ainda não conhece, é importante destacar que o NIC.br é a autoridade local de abrangência nacional na hierarquia da governança da Internet, que desde dezembro de 2005 implementa as decisões e projetos do Comitê Gestor da Internet no Brasil (CGI.br).

Abraço.

Samuel.

Mensagem ao Leitor do Blog - Resultado de Sorteio

Olá Pessoal.

No dia 01/02/2013 escrevi uma mensagem para todos os leitores assumindo o compromisso de sortear um exemplar do meu livro autografado para os membros do blog quando atingíssemos a marca de 100 pessoas na nossa comunidade técnica. Quem não estiver lembrado ou não acompanhava o blog nessa época, o anúncio foi intitulado "Mensagem ao Leitor do Blog".

Pois bem, como promessa é dívida e recentemente ultrapassamos a marca dos 100 membros cadastrados, hoje (08/05/2013) realizei o sorteio onde todos os membros cadastrados tinham seu nome presente. O leitor premiado foi:

- Thiago Pimentel, do Rio de Janeiro

Já fiz contato com o Thiago solicitando que ele me envie os dados completos do endereço onde deseja receber seu exemplar autografado do meu livro intitulado "Laboratórios de Tecnologias Cisco em Infraestrutura de Redes". 

Agora que esse sorteio foi realizado acho que já podemos pensar no próximo, não é mesmo? Pois bem, então vamos pensar grande! Assim que atingirmos a marca de 200 membros cadastrados no blog (isso mesmo, nada menos que 200), irei sortear um novo exemplar do meu livro autografado. Talvez demore um pouco para ultrapassarmos essa marca, mas há de acontecer e agora vocês já sabem que o sorteio realmente será realizado! ;-)

Se cada usuário cadastrado no blog indicá-lo para um colega da área que tenha interesse em redes/telecom e tecnologias Cisco, então é possível que o próximo sorteio ocorra logo. Espero que vocês estejam gostando do conteúdo aqui publicado e peço que todos colaborem com o crescimento desse espaço, afinal não é fácil mantê-lo atualizado! Aliás, estou trabalhando em alguns projetos e em breve trarei novidades bem interessantes para vocês...

Colaborem, divulguem, COMENTEM, COMPARTILHEM...

 

Abraço.

Samuel.

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.

Palestra Sobre o "Big Data" na UNIMEP

Olá Pessoal.

No próximo dia 06/05/2013 (segunda-feira) será realizada uma palestra na UNIMEP intitulada "Inteligência Coletiva e o Big Data: Tendências e Tecnologias". O objetivo do evento é apresentar algumas tendências da área de Tecnologia da Informação, abordando temas relacionados à Inteligência Coletiva e o "Big Data".

O evento é gratuito e aberto também para participação da comunidade externa! Todos os leitores do blog estão convidados, participem e tragam seus colegas...

> Palestrante: Nivaldo Tadeu Marcusso

Formado em Engenharia Eletrônica, com MBA em Conhecimento, Tecnologia e Inovação pela FIA/USP, MBA em Gestão Avançada na FIA/USP e Certificação em Estratégia e Inovação pela MIT Sloan School of Management. Possui Especialização em Gestão Estratégica de TI (SUIT) pela Stanford School of Business (2001), Estratégia e Serviços de TI (DIS) pela Havard Business School (2004), Direção Estratégica de TI pela FGV/SP (2002), Gestão de Conhecimento pela FIA/USP (2004), com extensão na Universidade de Lyon, Gestão Internacional pela FEA/FIPECAI e Universidade de Marseille e Inovação pela MIT Sloan School of Management (2006).

> Conteúdo Abordado:

O objetivo da palestra é apresentar como a inteligência coletiva está propiciando o desenvolvimento de novos modelos de negócios digitais e como a inteligência analítica está utilizando a produção massiva de informações, representada pelo "Big Data", para a oferta de produtos e serviços personalizados de acordo com o desejo de consumo dos clientes. Os participantes conhecerão as principais tecnologias disponíveis, arquitetura, soluções de mercado e as tendências de aplicação no desenvolvimento de novos serviços, produtos e a criação de novos mercados de consumo. 

> Data e Local do Evento:

UNIMEP - Universidade Metodista de Piracicaba

Rodovia do Açucar, Km 156 - Piracicaba (SP)

Campus Taquaral - Auditório Verde - Bloco 02

Informações: (19) 3124.1684

06/05/2013 às 19h30 

Abraço.

Samuel.

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.