Switches 3Com 4800G – RRPP (Topologia Single Ring)

Publicado originalmente em 21 DE JULHO DE 2010

O RRPP (Rapid Ring Protection Protocol) é um protocolo da camada de Enlace para topologias Ethernet em anel para prevenção de tempestades de Broadcast como alternativa para o Spanning-Tree.

O Rapid Ring Protection Protocol permite isolamento de domínios do STP (802.1d, 802.1s e 802.1w), muito utilizado em redes MetroEthernet para que a convergência do Spanning-Tree de cada site seja independente.

Em comparação com o 802.1d (STP), o RRPP possui as seguintes vantagens:

• Rápida convergência da topologia (por default 3 segundos em caso de não detecção dos pacotes Hello [as documentações do fabricante informam  o tempo de convergência menores que 50 milisegundos])

• Tempo de convergência independente do tamanho do anel (possibilita o diâmetro de 16 Switches em comparação de 7 do Spanning-tree)

No cenário abaixo, o Site 2 não troca mensagens BPDU’s com o Site 3, isto é, cada site teria o seu próprio Switch Root e tempo de convergência independente do outro, apesar de continuarem trocando mensagens de Broadcast que permitirão a comunicação entre todos os Sites como se os Switches estivessem fisicamente no mesmo local.

Mecanismo do RRPP

Cada Switch do Anel em uma topologia Simples (Single Ring) possui uma porta Primária (Primary) e uma porta Secundária (Secondary) que são definidas para identificação do estado da topologia.

Para prevenção de Loops a porta Primaria do único Switch Master do Anel encaminha mensagens Hello através da VLAN de controle a cada 1 segundo que será reencaminhada pelos Switches Transit (não Master).

Se a porta Secundária do Switch Master receber a mensagemHello encaminhada anteriormente pela porta Primária do Master, a porta Secundária irá bloquear os dados e permitirá somente as mensagens encaminhadas pela VLAN de controle, protegendo assim a topologia de Loops na rede.

Quando o anel é desfeito (por problemas no link), a porta secundária do Switch Master irá permitir tráfego de todas as VLANs.

Quando o Switch Transit percebe uma falha no link, ele encaminhará imediatamente uma mensagem Link-Down para o Switch Master. Após receber a mensagem, o nó Master irá permitir as VLANs da porta Secundária (anteriormente em estado de bloqueio).

Após receber a mensagem Link-Down, o Switch Master encaminhará para todos os nós Transit uma mensagemCommon-Flush-FDB para os nós atualizarem suas entradas ARP e MAC.

Quando o Nó Master identifica que o Anel foi restaurado, encaminha uma mensagem Complete-Flush-FDB para os outros nós do Anel para atualização das entradas ARP e MAC, pois a porta Secundária do Master entrará novamente em estado de bloqueio.

Obs: o Hello timer encaminhado pelo Master é de 1 segundo e o fail-timer (tempo para detecção da falha) é de 3 segundos. A rápida convergência do RRPP é provida pelas mensagens encaminhadas imediatamente dos Switches Transit para o Master quando é detectado uma falha no link que compõe o Anel.

Configuração

#
rrpp domain 1
!Criando o dominio RRPP 1
control-vlan 4093
!Especificando a VLAN 4093 para controle das mensagens RRPP
protected-vlan reference-instance 0 to 32
! Protegendo as VLANs mapeadas nas Instancias MSTP 0 a 32 como potegidas pelo RRPP
ring 1 node-mode master primary-port GigabitEthernet1/0/25 secondary-port GigabitEthernet1/0/26 level 0
!Especificando o Switch como Master ,a porta Gi1/0/25 como Primária e a Giga 1/0/26 como Secundária
ring 1 enable
!Ativando o anel 1
#
interface GigabitEthernet1/0/25
port link-type trunk
!Configurando a porta como trunk
port trunk permit vlan all
!Configurando o trunk para permitir todas as VLANs
stp disable
! Desabilitando o STP na interface Giga 1/0/25
qos trust dot1p
!Confiando na marcação 802.1p nas portas RRPP do Anel de cada dispositivo.
#
interface GigabitEthernet1/0/26
port link-type trunk
port trunk permit vlan all
stp disable
qos trust dot1p
#
rrpp enable
!Ativando o RRPP

Segue abaixo a configuração dos nós Transit:

#
rrpp domain 1
!Criando o dominio RRPP 1
control-vlan 4093
!Especificando a VLAN 4093 para controle das mensagens RRPP
protected-vlan reference-instance 0 to 32
! Protegendo as VLANs mapeadas nas Instancias MSTP 0a 32 como potegidas pelo RRPP
ring 1 node-mode transit primary-port GigabitEthernet1/0/25 secondary-port GigabitEthernet1/0/26 level 0
!Especificando o Switch como Transit ,a porta Gi1/0/25 como Primária e a Giga 1/0/26 como Secundária
ring 1 enable
!Ativando o anel 1
#
interface GigabitEthernet1/0/25
port link-type trunk
port trunk permit vlan all
stp disable
qos trust dot1p
#
interface GigabitEthernet1/0/26
port link-type trunk
port trunk permit vlan all
stp disable
qos trust dot1p
#
rrpp enable
!Ativando o RRPP

Comando Display

[Site1]display rrpp verbose domain 1

Domain ID : 1
Control VLAN : Major 4093 Sub 4094
Protected VLAN: Reference Instance 0 to 32
Hello Timer : 1 sec Fail Timer : 3 sec

Ring ID : 1
Ring Level : 0

Node Mode : Master
Ring State : Complete
Enable Status : Yes Active Status: Yes
Primary port : GigabitEthernet1/0/25 Port status: UP
Secondary port: GigabitEthernet1/0/26 Port status: BLOCKED

Comando display após falha no Anel

[Site1]display rrpp verbose domain 1

Domain ID : 1
Control VLAN : Major 4093 Sub 4094
Protected VLAN: Reference Instance 0 to 32
Hello Timer : 1 sec Fail Timer : 3 sec

Ring ID : 1
Ring Level : 0

Node Mode : Master
Ring State : Failed
Enable Status : Yes Active Status: Yes
Primary port : GigabitEthernet1/0/25 Port status: DOWN
Secondary port: GigabitEthernet1/0/26 Port status: UP

Referências

http://www.huawei.com/products/datacomm/pdf/view.do?f=71

http://pt.wikipedia.org/wiki/Ethernet_Automatic_Protection_Switching

 

 

Switches 3Com 5500 – Configurando QinQ (VLAN-VPN)

Publicado originalmente em 22 DE FEVEREIRO DE 2010

Conhecido também como Stacked VLAN, o QinQ suporta a utilização de duas TAGs 802.1q no mesmo frame para trafegar uma VLAN dentro de outra VLAN – sem alterar a TAG original.

A idéia é prover serviços aos clientes para manterem suas próprias VLANs dentro da rede do PROVEDOR, que poderá configurar uma VLAN para cada cliente independente da marcação 802.1q efetuada.

O comando vlan-vpn enable permite a utilização de QinQ.

Chamaremos os Switches 5500 de equipamentos do Provedor e os Switches 4210 e 4500 como Switches do Cliente.

No exemplo abaixo a comunicação entre o host A e B ocorrerá da seguinte forma:

1º – O Frame encaminhado pelo host A será marcado no Switch 4500 com a TAG 10 para o Switch 5500-A.
2º – O Switch 5500-A irá manter a informação da VLAN 10 e adicionará mais uma marcação com a TAG 100.
3º – O Switch 5500-B removerá a TAG 100 e encaminhará o Frame para o Switch 4210 com a TAG adicionada pelo Switch 4500.
4º – O Switch 4210 irá remover a TAG 10 e encaminhará o frame para o Host B

A estrutura do provedor (Switches 5500-A e 5500-B) será transparente para o cliente.

Segue abaixo as configurações efetuadas:

 

Switch 4210 
vlan 10
#
interface Ethernet1/0/1
port access vlan 10
#
interface GigabitEthernet1/0/27
port link-type trunk
port trunk permit vlan all

Switch 5500-A
vlan 100
#
interface GigabitEthernet1/0/25
stp disable
port access vlan 100
vlan-vpn enable
undo ntdp enable
#
interface GigabitEthernet1/0/26
port link-type trunk
port trunk permit vlan 1 100

Switch 5500-B vlan 100
#
interface GigabitEthernet1/0/25
stp disable
port access vlan 100
vlan-vpn enable
undo ntdp enable
#
interface GigabitEthernet1/0/26
port link-type trunk
port trunk permit vlan 1 100

Switch 4500 vlan 10
#
interface Ethernet1/0/1
port access vlan 10
#
interface GigabitEthernet1/0/27
port link-type trunk
port trunk permit vlan all

Percebam que nos equipamentos do Provedor, será necessário a configuração da porta de UpLink com o cliente como Access para não alterarmos a TAG inicial e também desabilitarmos o NTDP e STP.

Na configuração acima, os Switches 4210 e 4500 não irão trocar BPDUs, isto é, não haverá uma topologia única para o Spanning-Tree ( dos Switches do Cliente). Cada Switch do Cliente será Root da sua topologia (Os switches do Provedor, não participarão do Spanning-tree)

Para uma topologia única para o Spanning-tree do Cliente, será necessário configurarmos o comando vlan-vpn tunnel globalmente nos equipamentos da Operadora.
Segue abaixo configuração :

Switch 5500-A 
vlan-vpn tunnel
#
vlan 100
#
interface GigabitEthernet1/0/25
stp disable
port access vlan 100
vlan-vpn enable
undo ntdp enable
#
interface GigabitEthernet1/0/26
port link-type trunk
port trunk permit vlan 1 100

Switch 5500-B 
vlan-vpn tunnel
#
vlan 100
#
interface GigabitEthernet1/0/25
stp disable
port access vlan 100
vlan-vpn enable
undo ntdp enable
#
interface GigabitEthernet1/0/26
port link-type trunk
port trunk permit vlan 1 100

Comando display STP no Switch 4210:

display stp
-------[CIST Global Info][Mode MSTP]-------
CIST Bridge :32768.0024-73c4-7477
Bridge Times :Hello 2s MaxAge 20s FwDly 15s MaxHop 20
CIST Root/ERPC :32768.0022-5733-5280
CIST RegRoot/IRPC :32768.0024-73c4-7477
CIST RootPortId :128.25

Até logo!

 

 

IPv6 – Descoberta de Roteadores e Descoberta de Vizinhos

Publicado originalmente em 26 DE OUTUBRO DE 2011 em http://www.rotadefault.com.br/2011/10/26/ipv6-%E2%80%93-descoberta-de-roteadores-e-descoberta-de-vizinhos/

A comunicação entre hosts em uma rede local com  IPv6 ocorre inicialmente com a utilização de mensagens ICMPv6 para descoberta de dispositivos vizinhos . O assunto gerou uma discussão bem bacana no ultimo curso de IPv6 que participamos promovido pelo NIC.br na cidade de SP. A equipe está de parabéns pelo serviço oferecido, material e treinamento!

Para o  IP versão 6 foram atribuídas funções importantes ao ICMPv6 que combinam as atividades de protocolos como o ARP, ICMP Router Discover, ICMP Redirect e etc, além de adicionar novos métodos não existentes na versão anterior do protocolo IP. A facilidade de comunicação entre equipamentos é muito pratica e em determinados cenários dispensa configuração.

A eliminação de  endereços broadcast para descoberta de dispositivos  foram substituídas no IPv6 por mensagens com endereços Multicast como All-Routers, All-nodes, Solicited-Node, etc.

Para a comunicação entre dispositivos na LAN são utilizada as mensagens NS (Neighbor SolicitationICMPv6 tipo 135) e NA (Neighbor  Advertisement,ICMPv6 tipo 136) para mapeamento de endereço de rede e da camada de enlace, substituindo o ARP do IPv4.

Para a auto-configuração chamada de stateless de endereços globais (únicos, com acesso a Internet) para dispositivos da LAN, são utilizadas mensagens RS (Router Solicitation , ICMPv6 tipo 133) e RA (Router Advertisement, ICMPv6 tipo 134). Nesse caso o roteador encaminhará o prefixo de rede no segmento e os dispositivos interessados “anexarão” dinamicamente a porção de host do endereço (gerada do endereço MAC ou aleatóriamente para criar seu endereço global IPv6) além da rota default para o dispositivo.

Os protocolos de descoberta de vizinhos e descoberta de roteadores traz a possibilidade de desenvolvimento de cenários como a automação residencial onde todos os equipamentos de uma casa conversam entre si e possuem acesso a Internet, entre outros…

Como uma imagem vale mais do que mil palavras, segue um desenho explicativo para a troca de mensagens de solicitação de vizinhos e roteadores elaborado pelo Adilson Florentino no curso de IPv6; e rabiscado abaixo por nós…. ;)

Switches HP A7500 – IPv6, Autoconfiguração Stateless.

Publicado originalmente em 21 DE FEVEREIRO DE 2011

A Autoconfiguração Stateless de endereços para IPv6 permite aos hosts a atribuição automática de endereços de rede sem a necessidade de um servidor DHCP e/ou configuração manual nas máquinas.

O hosts IPv6 são capazes de autoconfigurar o endereço Global baseado no prefixo de rede anunciado pelo Gateway com o protocolo de Discovery, vinculando os 64 bits finais do endereço IPv6 com uma variação do endereço MAC do dispositivo( chamado de Interface Identifier IEEE EUI-64 format).

Por exemplo, digamos que um dispositivo com o endereço MAC 00:26:b9:ce:b8:90 receba do Roteador o prefixo 2001::/64 para autoconfiguração de endereço Stateless; o resultado é o seguinte endereço IPv6: 2001::226:b9ff:fece:b890/64.

Perceba no endereço que a porção responsável pelo identificador da Interface possui uma semelhança no endereço MAC citado anteriormente: 2001::226:b9ff:fece:b890/64

O endereço MAC possui  apenas 48 bits; e para completar os 64bits são inseridos no meio do endereço MAC os valores em hexadecimal FFEE.

Obs: Outro valor alterado para unicidade do endereço é o 7º Bit do endereço, que é alterado para o valor 1 ( chamado de bit  Universal/Local [U/L])

Configurando 

ipv6
#
interface Vlan-interface2
ipv6 address 2001::1/64
undo ipv6 nd ra halt
! Desativando a supressão de mensagens RA
(router advertisement) que são os anúncios do prefixo.

Nesse caso o host autoconfigurará o endereço baseado no prefixo da interface e terá o dispositivo como Gateway da estação.

Porém…
O leitor pode perguntar: – E a configuração de DNS?
Nesse exemplo, ainda precisaremos configurar o resolver para os hosts manualmente em IPv6 ou em IPv4.

Até logo! 🙂

 

 

IPv6 – Introdução ao Endereçamento e Cabeçalho

Publicado originalmente em 7 DE AGOSTO DE 2010

Olá Pessoal, hoje inicio mais um artigo referente ao IPv6. Tenho certeza que grande maioria dos técnicos de informática já ouviram  bastante coisa sobre o tema e mesmo assim, há uma incerteza de como isso funcionará e/ou afetará a maneira como lidamos com os endereços de rede e serviços.

Nos últimos meses tenho lido bastante coisa sobre o tema e após alguns laboratórios com os endereçamentos IP versão 6, venho percebendo que o assunto não é um bicho de sete cabeças!

Como informação nunca é de mais, postarei um resumo do meu trabalho entregue na Universidade e a dica do site http://ipv6.br/que possui um curso bacana (grátis) em português sobre o assunto…

O IP versão 6, atende todas as necessidade propostas para melhora da versão anterior. Genericamente, o IPv6 não é compatível com o IPv4, mas é compatível com os outros protocolos auxiliares da Internet, como TCP, UDP, ICMP, IGMP, DNS, etc.

A principal modificação está relacionada ao endereçamento de128 bits, comparado aos 32 bits do IPv4. O aumento na quantidade de endereços oferecem um número ilimitado de endereços na Internet, melhora na confiabilidade de endereços, flexibilidade e facilidade de multihoming para diversos Provedores (ISP), auto-configuração de endereços de rede IPv6 e comunicação fim-a-fim sem a necessidade de NAT.

Devido ao tamanho dos endereços IPv6, tornou-se impraticável a representação da mesma maneira que os endereços IPv4, como resultado, 8 grupos de 16 bits separados por dois-pontos (“:”) são representados em formato hexadecimal:

  • 1234:5678:9ABC:DEF0:1234:5678:9ABC:DEF0

Tendo em vista a utilização de vários endereços contendo números zero, essa porção do endereço poderá ser omitida e representada por dois dois-pontos(“::”). De modo que 0987poderá ser escrito como 987. Um ou mais grupos de 16bits zero podem ser substituídos por um par de dois-pontos . Os pares de dois-pontos utilizados na abreviação podem ser utilizados somente uma vez, para eliminar ambigüidade.

Como exemplo a abreviação do endereço2001:0002:0000:0000:00A1:0CC0:0234:9876 poderá ser da seguinte forma:

  • 2001:2:0:0A1:CC0:234:9876
  • 2001:0002::00A1:0CC0:0234:9876
  • 2001:2::A1:CC0:234:9876

Para o uso de mais de um IP em um mesmo dispositivo, foram criados os seguintes esquemas:

Unicast: similar aos endereços unicast IPv4, um endereço unicast IPv6 é endereçado para uma única interface. Uma interface poderá ter vários endereços unicast. Os endereços em unicast podem ser global, link-local, unique local(ULA) e IPv4 compatible.

Multicast: neste esquema, um único dispositivo consegue identificar várias interfaces na rede, permitindo o envio individual de pacotes; Um pacote enviado para um endereço multicast é entregue para todas as interfaces identificadas com o endereço multicast.

Anycast: o endereço IPv6 pode estar atribuído a mais de uma interface/dispositivo, ao invés de uma individual. Todos os nós com o mesmo endereço unicast proverão serviços de maneira uniforme. Um exemplo de serviço anycast é o balanceamento de entrega de serviços de conteúdo.

No endereçamento IPv4, o broadcast resulta em inúmeros problemas, incluindo problemas na rede conhecidos como tempestade de broadcast que podem parar a LAN completamente. O Broadcast não existem nas redes IPv6, os broadcasts foram substituídos por endereços multicast e anycast.

O segundo aperfeiçoamento importante no IPv6 é a simplificação do cabeçalho. O cabeçalho IPv4 contem 12 campos básicos contra 7 do IPv6. Esta mudança permite aos roteadores encaminharem os pacotes com maior agilidade, melhorando o throughput e o retardo.

O cabeçalho IPv6 contem os seguintes campos:

Version: possui 4 bits, o mesmo que no IPv4. No IPv6 o campo contem o numero 6.

Traffic class: possui 8 bits e função similar ao campo IPv4 type of service (ToS). Este campo marca o pacote para diferenciação de Qualidade de Serviço dos pacotes IP (QoS).

Flow Label: este novo campo possui 20 bits e poderá ser utilizado para a marcação na origem para especificação do pacote como parte de um determinado fluxo. O fluxo pode ser configurado com antecedência e ter um identificador atribuído a ele e forçando aos Switches Multicamadas e Roteadores verificar nas tabelas internas que tipo de tratamento especial ele exigem, para melhor encaminhamento e desempenho.

Payload lenght: determina o numero de bytes que seguem o cabeçalho de 40bytes.

Next header: o valor de 8 bits determina o tipo de informação que segue o cabeçalho IPv6 básico.O cabeçalho pode ser simplificado porque existe a possibilidade de haver outros cabeçalhos de extensão(opcionais).

Hop limit: campo de 8 bits com função similar ao campo TTL da versão 4

Source address: Campo de 128 bits que identifica a origem do pacote.

Destination address: Campo de 128 bits que identifica o destino do pacote.

Extension headers: Esses cabeçalhos podem ser criados com a finalidade de oferecer informações extras para tornar o encaminhamento mais rápido e eficiente. Estes cabeçalhos extras permitem uma maior eficiência, devido ao tamanho do cabeçalho, que pode ser ajustado às necessidades. Os cabeçalhos devem ser utilizados de forma encadeada permitindo uma maior flexibilidade, porque podem ser sempre adicionados novos cabeçalhos para satisfazer novas especificações. As especificações actuais recomendam a seguinte ordem:

1. IPv6

2. Hop-By-Hop Options Header

3. Destination Option Header

4. Routing Header

5. Fragment Header

6. Authentication Security Payload Header

7. Destination Options Header

8. Upper-Layer Header

O cabeçalho de autenticação, pertencente ao extension headers, oferecendo um mecanismo pelo qual o receptor de um pacote pode ter certeza de quem enviou. A carga útil de segurança criptografada torna possível criptografar o conteúdo do pacote. Esses cabeçalhos utilizam técnicas criptográficas para alcançar os objetivos a que se propõem. O IPsec torna-se nativo ao IPv6 com o authentication header (AH), com o next-header com o valor igual 51 e o cabeçalho Encapsulating Security Payload (ESP), com o next-header com o valor igual 50 que poderão ser utilizados dentro do IPsec para providenciar autenticação, integridade e confidencialidade do pacote.

Muitas das alterações incorporadas ao IP versão 6 referem-se a melhora no desempenho no encaminhamento dos pacotes como a remoção do campo checksum ( presentes na camada de enlace e transporte, tornando-a redundante no cabeçalho IP) e melhora no processo de fragmentação.

Na prática, o espaço de endereços não será utilizado com eficiência, mas haverá na versão 6 uma inesgotável quantidade de endereços para PDAs, pen-tablets, celulares, carros, eletrodomésticos, edifícios inteligentes, monitoramentos médicos e etc. Devido a isso os dispositivos poderão ter mais de um endereço IP tornando possivel que certos serviços sejam executados simultaneamente numa mesma máquina e para cada um haverá uma conexão exclusiva.

Cadê a Máscara do IPv6? 

Os endereços IPv6 trabalham diretamente com os prefixos, similar a representação atual que fazemos nas redes IPv4 ( 192.168.1.0/24) que representam a os bits de rede e os bits de host.

Para as redes locais é sugerido a utilização de prefixos /64, então se quiséssemos configurar o primeiro endereço válido da rede 2001:0db8:0000:000:0000:0000:0000:0000/64 em um roteador, poderiamos configurar com o endereço IPv6 na interface como ipv6 address 2001:db8::1/64 ( fácil, fácil )!

E vocês, qual a sua experiência com endereços IPv6 (alguma, nenhuma)? Comentem!!

Bibliografia
Redes de Computadores – 4ª edição
Andrew S. Tanenbaum
Building Scalable Cisco Internetworks – 3ª edição
Diane Teare

Referências
http://www.infowester.com/ipv6.php
http://www.faqs.org/rfcs/rfc1550.html
http://ipv6.br/

 

 

Switches 3Com 4800G – RIPng

Publicado originalmente em 5 DE AGOSTO DE 2010

Olá amigos, hoje escreverei um artigo sobre o RIPng, o primeiro post de uma série sobre IPv6.

O RIPng é um protocolo de Roteamento dinâmico, IGP, de vetor de distancia que permite que Roteadores troquem informações sobre as suas rotas/prefixos IPv6 dentro do domínio RIPng, utilizando-se da contagem de saltos como custo para cada prefixo (rede).

Assim como no RIP versão 1 e 2 (redes IPv4), o RIPng utiliza a contagem de até 15 saltos, conforme os Roteadores vão repassando os prefixos para os vizinhos é adicionado o custo 1 ao prefixo declarado em cada Roteador , o 16º salto é considerado inalcançável(infinito).

 

O RIPng possui os mesmos temporizadores (timers), procedimentos e mensagens que o RIP versão 2 ( 30 segundos para atualizações, 180 para timeout, 120 para garbage-collection e 180 segundos para holddown).

Diferente do RIP versão 2, a autenticação fica a encargo do IPv6. O RIPng encaminha e recebe datagramas UDP na porta 521.

Configurando o RIPng

• O Switch 1 possui o a rede 2001:db8:90::/64
o A comunicação com o Switch 2 será pela rede 2001:db8:1::/64
o A comunicação com o Switch 3 será pela rede 2001:db8:2::/64

• O Switch 2 possui o a rede 2001:db8:20::/64
o A comunicação com o Switch 1 será pela rede 2001:db8:1::/64
o A comunicação com o Switch 3 será pela rede 2001:db8::/64

• O Switch 3 possui o a rede 2001:0db8:30::/64
o A comunicação com o Switch 2 será pela rede 2001:db8::/64
o A comunicação com o Switch 1 será pela rede 2001:db8:2/64

Switch 1

sysname SW1
#
vlan 1 
#
vlan 2
#
vlan 90
#
ipv6
! Ativando o IPv6 
#
interface Vlan-interface1
ipv6 address 2001:DB8:1::1/64
! Configurando o endereço IPv6 2001:0db8:1::1/64 
ripng 1 enable
! Ativando o RIPng processo 1 na interface VLAN 1
#
interface Vlan-interface2
ipv6 address 2001:DB8:2::2/64
! Configurando o endereço IPv6 2001:db8:2::2/64 
ripng 1 enable
! Ativando o RIPng processo 1 na interface VLAN 2 
#
interface Vlan-interface90
ipv6 address 2001:DB8:90::1/64
! Configurando o endereço IPv6 2001:db8:90::1/64
ripng 1 enable
! Ativando o RIPng processo 1 na interface VLAN 90
#
interface GigabitEthernet1/0/31
#
interface GigabitEthernet1/0/32
port link-type access
port access vlan 2
#

Switch 2

sysname SW2
#
vlan 1
#
vlan 3
#
vlan 20
#
ipv6
#
interface Vlan-interface1
ipv6 address 2001:DB8:1::2/64
ripng 1 enable
#
interface Vlan-interface3
ipv6 address 2001:DB8::1/64
ripng 1 enable
#
interface Vlan-interface20
ipv6 address 2001:DB8:20::1/64
ripng 1 enable
#
interface GigabitEthernet1/0/25
#
interface GigabitEthernet1/0/26
port link-type access
port access vlan 3
#

Switch 3

#
sysname SW3
#
vlan 1
#
vlan 2
#
vlan 3
#
ipv6
#
interface Vlan-interface2
ipv6 address 2001:DB8:2::1/64
ripng 1 enable
#
interface Vlan-interface3
ipv6 address 2001:DB8::2/64
ripng 1 enable
#
interface Vlan-interface30
ipv6 address 2001:DB8:30::1/64
ripng 1 enable
#
interface GigabitEthernet1/0/47
port link-type access
port access vlan 3
#
interface GigabitEthernet1/0/48
port link-type access
port access vlan 2
#

Comandos Display

[SW3]display ipv6 routing-table 

Routing Table :
Destinations : 11 Routes : 12

Destination: ::1/128 Protocol : Direct
NextHop : ::1 Preference: 0
Interface : InLoop0 Cost : 0

Destination: 2001:DB8::/64 Protocol : Direct
NextHop : 2001:DB8::2 Preference: 0
Interface : Vlan3 Cost : 0

Destination: 2001:DB8::2/128 Protocol : Direct
NextHop : ::1 Preference: 0
Interface : InLoop0 Cost : 0

Destination: 2001:DB8:1::/64
Protocol : RIPng NextHop : FE80::224:73FF:FEE0:8481 Preference: 100
Interface : Vlan2 Cost : 1 

Destination: 2001:DB8:1::/64
Protocol : RIPng NextHop : FE80::224:73FF:FEDC:4381 Preference: 100
Interface : Vlan3 Cost : 1 

Destination: 2001:DB8:2::/64
Protocol : Direct NextHop : 2001:DB8:2::1 Preference: 0
Interface : Vlan2 Cost : 0

Destination: 2001:DB8:2::1/128 Protocol : Direct
NextHop : ::1 Preference: 0
Interface : InLoop0 Cost : 0

Destination: 2001:DB8:20::/64 Protocol : RIPng
NextHop : FE80::224:73FF:FEDC:4381 Preference: 100
Interface : Vlan3 Cost : 1

Destination: 2001:DB8:30::/64 Protocol : Direct
NextHop : 2001:DB8:30::1 Preference: 0
Interface : Vlan30 Cost : 0

Destination: 2001:DB8:30::1/128 Protocol : Direct
NextHop : ::1 Preference: 0
Interface : InLoop0 Cost : 0

Destination: 2001:DB8:90::/64 Protocol : RIPng
NextHop : FE80::224:73FF:FEE0:8481 Preference: 100
Interface : Vlan2 Cost : 1

Destination: FE80::/10 Protocol : Direct
NextHop : :: Preference: 0
Interface : NULL0 Cost : 0

Um detalhe importante a ser percebido (grifado em vermelho) na visualização da tabela de Roteamento IPv6, são as rotas aprendidas dinâmicamente pelo RIPng. Repare que o endereço do NextHop (próximo salto) foi gerado dinamicamente pelo RIPng.

 

O endereço FE80::/10 é reservado para endereços chamados de Link-local que possuem escopo limitado e são utilizados para configuração automatica de endereços, descoberta de rotas e por diversos Protocolos de Roteamento.

No caso dos links Ethernet é utilizado a derivação do endereço MAC (48 bits) do Switch para gerar um endereço de 64 bits, por exemplo, o Switch 1 possui o endereço MAC 0024-73e0-8480. O NextHop para a rede 2001:db8:90::/64 mostrado na tabela de roteamento IPv6 do SW3 é :

Destination: 2001:DB8:90::/64 Protocol : RIPng
NextHop : FE80::224:73FF:FEE0:8481 Preference: 100

Note que é inserido 16 bits (FFFE) entre o endereço MAC para criação automática do endereço Link Local.

Obs: A especificação do próximo salto para o RIPng sempre será um Link local.

 

[SW3]display ripng 1 route
Route Flags: A - Aging, S - Suppressed, G - Garbage-collect
----------------------------------------------------------------

Peer FE80::224:73FF:FEDC:4381 on Vlan-interface3
Dest 2001:DB8::/64,
via FE80::224:73FF:FEDC:4381, cost 1, tag 0, A, 19 Sec
Dest 2001:DB8:20::/64,
via FE80::224:73FF:FEDC:4381, cost 1, tag 0, A, 19 Sec
Dest 2001:DB8:1::/64,
via FE80::224:73FF:FEDC:4381, cost 1, tag 0, A, 19 Sec

Peer FE80::224:73FF:FEE0:8481 on Vlan-interface2
Dest 2001:DB8:2::/64,
via FE80::224:73FF:FEE0:8481, cost 1, tag 0, A, 17 Sec
Dest 2001:DB8:90::/64,
via FE80::224:73FF:FEE0:8481, cost 1, tag 0, A, 17 Sec
Dest 2001:DB8:1::/64,
via FE80::224:73FF:FEE0:8481, cost 1, tag 0, A, 17 Sec

Aos poucos irei adicionando outros posts sobre IPv6.

Espero que tenham gostado!

Abraços

 

 

Switches 3Com 4800G – IGMP Snooping

Publicado originalmente em 3 DE OUTUBRO DE 2010

O Protocolo IGMP permite que hosts registrem-se a um Grupo Multicast encaminhando/ respondendo mensagens IGMP ao Roteador da LAN. Roteadores e Switches de Camada 3 escutam as mensagens IGMP para encaminhar o fluxo para o segmento solicitante.
 Após o Switch Core receber o tráfego Multicast do Servidor, ele precisa decidir sobre o encaminhamento do tráfego Multicast nos links Ethernet (após satisfazer as seguintes questões):
  • Existe algum usuário conectado em meus links Ethernet que está interessado em receber o tráfego Multicast?
  • Se nenhum host está interessado em receber o tráfego Multicast, haveria necessidade de encaminhar o tráfego e consumir banda?
  • Se existe um host interessado em receber o tráfego, onde ele está localizado?

Em cima dessas questões, o IGMP foi desenvolvido para estabelecer encaminhamento do tráfego Multicast entre o Roteador e/ou Switch de Camada 3 e as máquinas com as mensagens Join, Query e Leave.

JOIN
Antes de o computador receber o tráfego Multicast, ele necessita efetuar um “Join” no grupo Multicast encaminhando um IGMP Report ao Roteador. O Roteador IGMP encaminha mensagens IGMP Query periodicamente esperando a resposta IGMP Report de algum host para continuar encaminhando tráfego Multicast.

Obs: O computador pode encaminhar um Join antes sem esperar a mensagem IGMP Query do Roteador!

LEAVE
A partir do IGMP versão 2, os hosts que não querem receber o trafego Multicast encaminham uma mensagem IGMP Leave. O Roteador Multicast, encaminha uma nova mensagem IGMP Query questionando se há mais algum computador na rede interessado no tráfego, se não houver resposta, o tráfego Multicast não será encaminhado para o segmento.

IGMP Snooping
Por default, após o Join de um host ao grupo Multicast, o tráfego é inundado para todas as portas dos Switches de acesso que pertencem a VLAN que efetuou a requisição.

  1. O Servidor da VLAN 10 inicia a transmissão do tráfego Multicast
  2.  ALGUNS Hosts da VLAN 192, encaminham uma mensagem IGMP Report (Join) para recebimento de tráfego do Grupo Multicast 239.1.1.1
  3.   O Fluxo Multicast é encaminhado para todas as portas da VLAN 192, incluindo as portas das máquinas que não estão interessadas no conteúdo.

Para evitar a inundação do tráfego Multicast ( transformando o comportamento do tráfego em Broadcast), a feature IGMP-Snooping monitora as mensagens IGMP Report, Query e Leave para adicionar somente as interfaces que desejam receber o fluxo na tabela CAM.

Dessa forma o IGMP Snooping permite aos Switches encaminhar o tráfego Multicast somente para os grupos Multicasts desejados, evitando desperdício de banda e otimizando os Recursos.

 

Comandos do Switch 4800G

#
igmp-snooping
!Habilitando o IGMP-Snooping globalmente

vlan 192
 igmp-snooping enable
!Habilitando o IGMP-Snooping na VLAN 192.

Display

 [4800G] display igmp-snooping group vlan 192
  Total 1 IP Group(s).
  Total 1 IP Source(s).
  Total 1 MAC Group(s).
 Port flags: D-Dynamic port, S-Static port, C-Copy port
  Subvlan flags: R-Real VLAN, C-Copy VLAN
  Vlan(id):1.
    Total 1 IP Group(s). Router port(s):total 1 port.
            GE1/0/48              (D)
! Interface identificada como Porta de conexão com o Roteador,
onde as mensagens Query são geradas
    Total 2 IP Source(s).
    Total 1 MAC Group(s).
    IP group(s):the following ip group(s) match to one mac group.
!Interfaces que efetuaram a solicitação para recebimento de fluxo Multicast
      IP group address:239.1.1.1
        (0.0.0.0, 239.1.1.1):
          Host port(s):total 2 port.

            GE1/0/34              (D)
            GE1/0/38              (D)
    MAC group(s):
          Host port(s):total 2 port.
            GE1/0/34
            GE1/0/38
      MAC group address:0100-5e01-0101
!Endereço MAC do Grupo Multicast e tabela de encaminhamento

Obs: Para configuração do Roteamento Multicast entre VLANs, consultem os tópicos Multicast do Blog ou deixem um comentário!

Abraços a todos!

Referência; CCIE Routing and Switching Exam Certification Guide, 4rd Edition [Odom, Healy, Mehta]

 

 

Switches 3Com 5500 – Configurando Roteamento Multicast com PIM DM

Publicado originalmente em 10 DE SETEMBRO DE 2010

Durante um evento na sala de reunião da Empresa X, a Diretoria solicitou a equipe de TI que a reunião fosse retransmitida e para o departamento de Marketing da Empresa.

Como solução para a solicitação os Analistas decidiram utilizar o Roteamento Multicast para exibir o vídeo somente para os funcionários do departamento interessados, ao invés de encaminhar o vídeo para toda a empresa!

Para exibição do Stream (Fluxo)de Vídeo foi utilizado o endereço de Multicast Privado 239.1.1.1. Os Hosts da VLAN Marketing que estiverem interessados em visualizar o conteúdo precisarão buscar o endereço informado.

Segue abaixo a configuração do cenário:

#
multicast routing-enable
! Habilitando o Roteamento Multicast no Switch L3
#
vlan 10
#
vlan 172
#
vlan 192
#
interface Vlan-interface10
ip address 10.0.0.1 255.255.255.0 
pim dm
! Configurando a Interface VLAN para encaminhar mensagens Multicast utilizando o protocolo de Roteamento Multicast PIM Dense Mode
#
interface Vlan-interface172
ip address 172.31.1.1 255.255.255.0
igmp enable
! O Protocolo IGMP é responsável por identificar se os hosts da VLAN 172
querem ou não visualizar o vídeo Multicast
pim dm
! Configurando a Interface VLAN 172 para encaminhar mensagens Multicast
utilizando o protocol de Roteamento Multicast PIM Dense Mode

Comando Display

display multicast routing-table
Multicast Routing Table
Total 1 entry
(10.0.0.100, 239.1.1.1)
! O host 10.0.0.100 gera o fluxo com o endereço Multicast 239.1.1.1
Uptime: 00:22:15, Timeout in 285 sec
Upstream interface: Vlan-interface10(10.0.0.1)
Downstream interface list:
Vlan-interface172(172.31.1.1) 
.....

Pronto, roteamento Multicast funcionando!

 

 

Switches 3Com 4800G- Utilização de alias …

Publicado originalmente em 27 DE ABRIL DE 2010

Hoje postarei mais uma dica apresentada pelo grande Fernando Quintino, que é a utilização de alias para facilitar a administração dos Switches 4800G da 3Com por CLI (linha de comando).

O artigo de hoje é focado para os administradores que possuem uma Rede com equipamentos de diversos fabricantes e sempre se confundem com os comandos digitados na hora da configuração/troubleshooting.

command-alias enable
! ativando a utilização de alias
command-alias mapping display show
! mapeando a utilização do comando "show" para funções "display"
command-alias mapping undo no
! mapeando utilização do comando "no" para funções "undo"
command-alias mapping quit exit
! mapeando utilização do comando "quit" para funções "exit"

Na prática poderiamos digitar o comando show version ou invés de display version, no shutdown ao invés de undo shutdown e quit ao invés de exit.

As alterações ficarão ao gosto do cliente…. 🙂

abraços

 

 

Switches 3Com 4500G – Upgrade via FTP

Publicado orignalmente em 26 DE ABRIL DE 2010

O post de hoje sugerido pelo Fernando Quintino ensinará como efetuarmos a cópia de arquivos para a memória Flash do Switch 4500G.

No exemplo abaixo o Servidor 1.1.1.2 com o Serviço FTP ativo ( com usuário anonymous e senha em branco) servirá de repositório para o Switch efetuar o download da imagem para a memória Flash do Switch, incluíndo a configuração para o equipamento iniciar com o novo arquivo.

Cópia de aqruivos via FTP

Configuração

 <4500G>ftp 1.1.1.2
! Conexão do Switch no Servidor FTP
user: anonymous
password: [Senha em Branco]
[ftp]ls
! listagem dos arquivos do diretório do FTP
[ftp] get s3q05_02_00s56p12.app
! o comando get efetuará o download do arquivo no repositório
[ftp] get s3r05_03.btm
[ftp]quit
! o comando efetuará logoff do servidor FTP

Obs: Após efetuarmos o download do arquivo .app e .btm poderemos configurar no Switch a inicialização da imagem no próximo boot

<4500G>boot-loader file s3q05_02_00s56p12.app main
!O comando boot-loader define qual imagem será escolhida como principal e backup na
inicialização do Switch.
 <4500G>bootrom update file s3r05_03.btm
!No documento de liberação da imagem s3q05_02_00s56p12.app, a H3C/3Com solicita o upgrade do bootrom.

Após efetuar as configurações, reinicie o equipamento.

 <4500G>reboot

Até a próxima! 😉