Monthly Archives: julho 2012

Switches HPN 12500 – MPLS – Configuração Básica

Dando continuidade aos posts anteriores sobre MPLS, segue abaixo a configuração básica para ativar o serviço em um Switch HPN modelo A12500. O script dará foco no protocolo LDP para adjacência entre roteadores vizinhos e a troca de labels; em conjunto com o OSPF para o vinculo (binding) dos prefixos IP com  labels.

Configuração

#
interface LoopBack1
 ip address 1.1.1.1 255.255.255.255
#
mpls
! Ativando o Serviço MPLS no Switch
#
mpls ldp
! Ativando o protocolo LDP para troca de labels
#
mpls lsr-id 1.1.1.1
! Forçando o Router id com o endereço da Loopback para adjacência
! entre Roteadores  vizinhos
#
interface Vlan-interface1
 ip address 10.0.0.1 255.255.255.0
 mpls
! Ativando o Serviço na interface VLAN 1
 mpls ldp
! Ativando o protocol LDP para troca de Labels na
! Interface VLAN 1 e adjacência
#
interface Ten-GigabitEthernet0/0/34
 port link-mode route
 ip address 10.0.1.2 255.255.255.252
mpls 
mpls ldp
#
ospf 1
 area 0.0.0.0
 network 0.0.0.0 255.255.255.255
 #

Displays

Para visualização dos neighbors, LSP e bindings, sugiro os seguintes comandos abaixo:

[Switch] display mpls ldp peer

[Switch] display mpls ldp session

[Switch] display mpls ldp interface

[Switch]display mpls ldp lsp
                              LDP LSP Information
 SN     DestAddress/Mask   In/OutLabel   Next-Hop        In/Out-Interface 

26     192.168.1.0/24       25/26     10.0.1.1          XGE0/0/34
27     192.168.0.1/32      2236/3043     192.0.0.5      XGE0/0/34
28     192.168.3.1/32     1037/1044     192.0.0.5       XGE0/0/34

[Switch]display mpls ldp
                           LDP Global Information

 Protocol Version        : V1           Neighbor Liveness    : 120 Sec
 Graceful Restart        : Off          FT Reconnect Timer   : 300 Sec
 MTU Signaling           : Off          Recovery Timer       : 300 Sec
                          LDP Instance Information

 Instance ID             : 0            VPN-Instance         :
 Instance Status         : Active       LSR ID               : 1.1.1.1
 Hop Count Limit         : 32           Path Vector Limit    : 32
 Loop Detection          : Off
 DU Re-advertise Timer   : 30 Sec       DU Re-advertise Flag : On
 DU Explicit Request     : Off          Request Retry Flag   : On
 Label Distribution Mode : Ordered      Label Retention Mode : Liberal

Até logo!

Introdução ao MPLS (Multi Protocol Label Switching) – parte 2

Essa semana publicamos no RotaDefault o segundo artigo introdutório sobre MPLS com comentários sobre a nomenclatura  de alguns termos como Roteadores CE, PE e P, informações sobre FEC, LSP e etc.

O Artigo poderá ser lido no link abaixo:

 http://www.rotadefault.com.br/2011/12/03/introducao-ao-mpls-multi-protocol-label-switching-%e2%80%93-parte-2/

A configuração para equipamentos HPN foi publicada no post :

http://comutadores.blogspot.com/2011/11/switches-hpn-12500-mpls-configuracao.html

Até logo!

Introdução ao MPLS (Multi Protocol Label Switching) – parte 1

Publicado originalmente em 20 DE OUTUBRO DE 2011

Essa semana publiquei no site RotaDefault um artigo introdutório sobre MPLS que será dividido em algumas partes. O mesmo servirá de gancho para alguns posts sobre a configuração de LDP, MP-BGP e VPLS em Roteadores e Switches HPN.

O artigo está emhttp://www.rotadefault.com.br/2011/10/20/introducao-ao-mpls-multi-protocol-label-switching-%e2%80%93-parte-1/

Obs: No final do artigo há a indicação de alguns livros interessantes que usei como referência!

Abraços a todos

Spanning-tree – Manipulando o Custo do Caminho para o Root (Path Cost)

Para criar uma rede livre de Loops, o Protocolo Spanning-tree (802.1d) utiliza 4 processos:

1º Processo
Eleição do menor Bridge ID para escolher o Switch Root

2º Processo
Eleição do menor caminho para o Root

3º Processo
eleição do menor Bridge ID do Switch que está encaminhando o BPDU do Root

4º Processo
Eleição do menor Port ID

Todo Switch da LAN (exceto os “Switches-Hub”) , recebe informações sobre os outros Switches da rede através da troca de mensagens chamadas de BPDUs (Bridge Protocol Data Units) que são encaminhados a cada 2 segundos em todas as portas para garantir a estabilidade da rede.

Entretanto, se a porta recebe um BPDU mais interessante (1º processo) de outro Switch, ele parará de gerar mensagens BPDUs e apenas encaminhará as mensagens desse dispositivo.

Baseado nas informações do Bridge ID dentro dos BPDUs os switches são capazes de:

- Eleger um Switch único, entre todos da LANs, para ser o Root Bridge (Raiz).

A partir do Switch Root os outros Switches da Rede escolherão o melhor caminho(baseado no custo do ponto de vista do Switch não-Root) para o Switch Root e bloquearão os caminhos redundantes para evitar loops na rede.
No exemplo acima (utilizando o custo das portas estabelecido no primeiro padrão do STP) a porta Fa0/1 (custo 19) do Switch não-Root ficará no estado de Bloqueio pois possui o MAIOR custo para chegar ao Root em comparação com a porta G0/1 (custo 4).

Existem cenários que é necessário manipular o path cost (custo do caminho) para escolha do melhor caminho para o Root visto que o meios físicos escolhido para transmissão dos quadros é mais suscetível a interferências, etc.

No exemplo abaixo a Empresa X possui 2 Switches com todas as portas GigabitEthernet para interligação entre 2 prédios distantes. Para conexão entre esses 2 dispositivos,foi utilizado fibra óptica e devido ao alto custo para passagem de nova infra-estrutura para redundância foi decidido a utilização de antenas (wireless) para contingência.

Se apenas tivéssemos manipulado o valor do Bridge ID do Switch Root, a eleição da porta Bloqueada basearia-se no 4º processo ( eleição do menor port ID, no sentido Root –> não-Root), pois o custo para o Root sofreria empate no 2º processo.

Para resolução desse cenário, poderia utilizar as seguintes tarefas:

1º Inverter as portas do Switch Root (G0/1 para Fibra e G0/2 para conexão sem fio); ou…

2º Aumerntar o Custo da porta G0/1 do Switch não-Root para alterarmos os estados das portas.

Configuração

Para a configuração da maioria dos Switches 3Com (no exemplo acima ), digite o comando dentro da Interface G1/0/1 do Switch não-Root:

interface Gi1/0/1
stp cost 19

Nesse caso a conexão com fibra ficaria ativa pelo MENOR custo  e o link wireless (redundante)  em estado de bloqueio!

Bom, é isso….

Até mais!

 

Como funciona a Auto-negociação?

Publicado originalmente em 17 DE FEVEREIRO DE 2010

A auto-negociação é uma protocolo da Camada Física do modelo de referência OSI, que permite que dois equipamentos de rede (Switches, Roteadores e Servidores) negociem velocidade eduplex para escolha dinâmica do melhor cenário para a comunicação de dados.

O padrão é bastante útil no dimensionamento de redes para a compatibilidade entre as versões 10/100/1000Mb das interfaces.

Apesar da instabilidade inicial do padrão (devido à incompatibilidade dos fabricantes na adoção do modelo), as discussões da especificação da auto-negociação foram eliminados pela versão de 1998 do IEEE 802.3. Em 1999, o protocolo de negociação foi significativamente ampliado por IEEE 802.3ab, que especificava o protocolo de GigabitEthernet, tornando obrigatória a auto-negociação para 1000BASE-T.

A auto-negociação é utilizada por dispositivos com diferentesvelocidades de operação (como 10Mb e 1Gb) e diferentes modos de operação duplex (Half-duplex e Full-duplex).

A incompatibilidade de duplex (duplex mismatch) ocorre quando um dispositivo está em full-duplex e o outro está funcionando em half-duplex. Por causa desse cenário um grande número de colisões irá ocorrer no lado half-duplex. Uma segunda ressalva é que interfaces configuradas manualmente não funcionam adequadamente com interfaces configuradas como auto-negociação.

Problemas de duplex mismatch são comuns e difíceis de diagnosticar, pois a rede continua a funcionar; e em testes básicos de troubleshooting, reportam uma conexão ativa, mas a rede funciona com lentidão.

Melhores práticas
Certifique-se que ambos os lados do link estão configurados da mesma maneira”.(Gary A. Donahue , Network Warrior, O’Reilly, 2007, p22)

Configurando a Auto-negociação 

Em Switches 3Com a auto-negociação está habilitada por default:

speed { 10 100 1000 auto }
duplex { auto full half }

Exemplo de configuração de speed e duplex em auto:

[Switch-GigabitEthernet1/0/1]duplex auto
#
[Switch-GigabitEthernet1/0/1]speed auto

Referências:

Wikipedia – http://en.wikipedia.org/wiki/Autonegotiation
Ethermanage – http://www.ethermanage.com/ethernet/100quickref/ch13qr_3.html

Script de Configuração NQA com Tracking (IP SLA)

A dica de utilização do NQA foi encaminhada pelo Leandro Cândido: “Caros, estava testando a Feature de NQA + TRACK  (SIMILAR AO IP SLA DO CISCO), pois iríamos precisar utilizar em um dos nossos clientes, e vi que funciona perfeitamente bem. Então, estou encaminhando o script caso alguém precise aplicar em algum projeto que envolva equipamentos 8800, 4800, 7900 e outros…”

A Feature NQA (Network Quality Analizer) permite o diagnóstico de desempenho de Links para verificação de Jitter, atraso de conexão TCP, FTP, ICMP e etc.

O NQA realiza testes utilizando pacotes ICMP echo, DHCP, FTP, HTTP, UDP jitter, SNMP, TCP, UDP echo, voz e DLSw.

No exemplo abaixo utilizaremos o NQA para testar o link principal com pacotes ICMP (PING). Em caso de falha do Link, o NQA permitirá ao Switch utilizar uma segunda a rota default para encaminhar o tráfego para o Link Redundante.

Utilizaremos o primeiro Roteador da Operadora A (Link principal) como Objeto para “rastrear” o Link como ativo.

Configuração

Nessa primeira parte do Script efetuaremos o vínculo do NQA (responsável por gerar os pacotes ICMP) com o Track.

 

nqa entry empresax rota_monitorada_via_icmp
!Criando o grupo NQA empresax rota_monitorada_via_icmp
type icmp-echo
! definindo o tipo de pacote como ICMP
destination ip 200.1.2.3
! endereço monitorado no primeiro salto da Operadora A
frequency 500
! a freqüência do teste será a cada 500ms
reaction 1 checked-element probe-fail threshold-type consecutive 4 action-type trigger-only
! Se a reação 1 identificar 4 falhas no objeto monitorado, ele será invalidado 

nqa schedule empresax rota_monitorada_via_icmp start-time now lifetime forever
!ativando o tempo de monitoração como infinito
nqa agent enable

track 1 nqa entry empresax rota_monitorada_via_icmp reaction 1
!Associando o track 1 ao NQA empresax

Obs: Até agora apenas criamos o NQA para monitorar o endereço do primeiro salto da Operadora A (é possível identificarmos esse endereço com o comando traceroute para qualquer endereço de internet) e vinculamos ao Track. A idéia agora é vincularmos a rota default principal como Objeto do Track, para invalidarmos a rota em caso de falha no link.

ip route-static 0.0.0.0 0.0.0.0 192.0.1.1 track 1 preference 1 descripition rota_principal
! Associando a rota estática com preferência 1 ao Track 1
ip route-static 200.1.2.3 255.255.255.255 192.0.1.1 descripition roteador_operadoraA
! A rota estática  está forçando a monitoração do Link Principal pelo roteador 192.0.1.1 
! evitando chegarmos no Roteador da operadora A via Operadora B em caso de falha no link principal

ip route-static 0.0.0.0 0.0.0.0 192.0.2.1 preference 60 description rota_backup
! rota de backup com preferência 60

Comandos Display

[4800G] display track 1
Track ID: 1
Status: Positive
! Rota principal funcionando
Reference object:
NQA entry: empresax rota_monitorada_via_icmp
Reaction: 1

[4800G]display nqa statistics
NQA entry(admin empresax, tag rota_monitorada_via_icmp) test 
statistics:
NO. : 1
Destination IP address: 200.1.2.3 
Start time: 2000-04-26 13:14:57.0 
Life time: 2612 
Send operation times: 2510 Receive response times: 2067 
Min/Max/Average round trip time: 3/460/4 
Square-Sum of round trip time: 553275 

Extended results:
Packet lost in test: 17% 
Failures due to timeout: 443
Failures due to disconnect: 0 
Failures due to no connection: 0
Failures due to sequence error: 0 
Failures due to internal error: 0
Failures due to other errors: 0

Packet(s) arrived late: 0

[4800G]display ip routing-table 
Routing Tables: Public
Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/0 Static 1 0 192.0.1.1 Vlan1 
!Tráfego encaminhado via interface vlan 1, antes do problema no link

Após a falha

Se o resultado do teste NQA der negativo, isto é, 200.1.2.3 como inalcançável, (o status do Objeto Track é Negative) a rota estática será inválida.

[4800G]display track 1 
Track ID: 1
Status: Negative
!Momento em que ocorre o problema no link, rota principal para de funcionar 
Reference object:
NQA entry: empresax rota_monitorada_via_icmp
Reaction: 1

[4800G]dis ip routing-table 
Routing Tables: Public
Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/0 Static 60 0 192.0.2.1 Vlan3 
! Agora o Tráfego será encaminhado via interface vlan 3. Se o link principal 
! voltar a comunicar, a rota default com preferência 1 voltará para tabela de 
! rotas excluíndo a de preferência 60

O que acharam do NQA? já tiveram alguma experiência com essa feature? Comentem…

Abraços

Utilizar o Spanning-Tree, sim ou não?

Publicado originalmente em 16 DE MAIO DE 2010

Olá amigos, a idéia desse post partiu de uma discussão com um colega sobre a razão dele não utilizar e não confiar no Protocolo Spanning-Tree ao ponto de desabilitá-lo em todos os Switches da rede.

O administrador dessa rede sempre priorizou a idéia do controle total sobre a topologia, sem redundâncias com o argumento de que em caso de falhas na rede é preferível perder algumas dezenas de minuto na troca do suposto equipamento (ou meio físico defeituoso) ao invés de não conseguir identificar problemas de convergência na Topologia.

Nessa mesma rede que chamaremos de Empresa X, todos os UpLinks estão conectados no Switch Core com um único cabo, sem caminhos alternativos ou redundância. Então faço a seguinte pergunta: O administrador dessa rede está correto? Eu diria que sim… Se não houver redundância ou Loop Físico entre os Switches não há função para o Spanning-Tree.


Mas é possível possuir o controle total da rede? Podemos confiar que um usuário não irá conectar um “Switch Hub” na rede para prover mais pontos ou ligar sem querer um ponto de rede do equipamento no próprio Switch?

O Protocolo Spanning-Tree poderia ajudar o Administrador da Empresa X em casos como esse bloqueando o Loop físico e/ou permitindo a utilização de meios físicos redundantes como fibra, cabo UTP ou via Wireless.

Na prática se o Switch estiver com o Spanning-Tree habilitado, irá encaminhar BPDUs -mensagens geradas pelo Root da Topologia . A rede efetuaria a convergência com o mínimo de perda em caso de falhas no meio físico ou Switches, deixando a disponibilidade dependente apenas dos timers do Max Age e do Forward Delay.

Olhando o desenho, quem é o Switch Root da Rede?

Em breve escreverei mais artigos sobre o STP. Dúvidas ou criticas? Deixem comentários!

Abraços

Switches 3Com 4800G – Upgrade do Sistema Operacional por TFTP

No modo user-view é possível efetuarmos a cópia de arquivos no sentido Switch x Servidor (PUT) ou Servidor x Switch (GET). O TFTP é o modo mais utilizado para cópia de arquivos com o objetivo de atualização de extensões como .bin, .btm, .cfg,etc.

É necessário configurarmos ao menos um endereço IP no Switch, além de validarmos comunicação entre o Servidor TFTP e o Switch.

A sintaxe para cópia de arquivos para o Switch é a seguinte:

Tftp [ip do servidor TFTP] get [nome do arquivo no servidor TFTP]

Uma outra opção para utilizarmos o comando TFTP é para o Backup de configurações/arquivos no servidor TFTP. A sintaxe necessária para a cópia de arquivos para o Servidor TFTP é a seguinte:

Tftp [ip do servidor TFTP] put [nome do arquivo no Switch]

Para transformar a sua máquina em um Servidor TFTP podemos utilizar diversos softwares grátis como o Solarwinds TFTP Server,tftpd32 e etc.

No exemplo abaixo o Switch efetuará a cópia dos arquivos s4800g-cmw520-r2202p15-s56.bin e S4800G-BTM_604.btm do Servidor TFTP para a memória Flash do Switch 4800G e configuraremos o dispositivo para iniciar com a imagem na próxima vez que reiniciar!

Copiando o arquivo .bin e .btm para o Switch

<4800G>tftp 192.168.1.68 get s4800g-cmw520-r2202p15-s56.bin

<4800G>tftp 192.168.1.68 get S4800G-BTM_604.btm

Até agora, só copiamos os arquivos para o Switch, nos exemplos abaixo ensinaremos como configurar o Switch para utilizar as novas imagens!!

Boot-loader
O comando boot-loader define qual imagem será escolhida como principal e backup na inicialização do Switch. Por Exemplo, após atualização por TFTP da imagem atual do Switch de                              s4800g-cmw520-r2102p02.bin para s4800g-cmw520-r2202p15-s56.bin, precisaremos informar ao equipamento qual versão do Sistema Operacional iremos utilizar no próximo boot. Digite:

<4800G>boot-loader file S4800G-cmw520-r2202p15-s56.bin main

Bootrom
No documento de liberação da imagem s4800g-cmw520-r2202p15-s56.bin, a H3C/3Com solicita o upgrade do bootrom. Digite:

<4800G>bootrom update file s4800g-btm_604.btm

Após efetuados os passos acima, reinicie o equipamento com o comando reboot

Problemas
Em caso de problemas na transferência de arquivos verifique:

  • Se há espaço disponível na memória flash do Switch com o comando dir no modo user-view
  • Verifique se o firewall do Servidor está bloqueando a transferência
  • Identifique se o serviço TFTP está ativo no computador.
  • Verifique se a pasta de destino configurada no Servidor para coleta dos arquivos está com o caminho correto no Software de TFTP

Em caso de problemas após efetuar a cópia e configurar o bootloader/bootrom no Switch , o mesmo ficará reiniciando ( após inumeras tentativas de subir o Sistema Operacional), pressione ctrl + B na seguinte tela, provavelmente o password estará em branco (pressione Enter):

 O Switch cairá no modo Bootrom sem nenhuma configuração, mas será possivel com a opção 2 selecionar os arquivos para Boot ( em caso de erro) ou com a opção 1 copiar novamente os arquivos para a Flash, etc. O Switch permitirá nos menus a configuração de endereço IP para nova cópia!

Dúvidas, deixe um comentário!!