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

quarta-feira, 3 de junho de 2009

Cisco Reverse Telnet

Em localidades remotas com poucos equipamentos (um roteador e um switch, por exemplo) e quando não há um servidor de console disponível, pode-se utilizar a porta auxiliar de um roteador Cisco para conectar-se a console de outro equipamento. Isto é comumente chamado de Reverse Telnet.

Para começar é necessário um cabo do tipo rolled - aquele mesmo azul claro que se acumula aos montes no seu depósito e que uma ponta do cabo está na ordem inversa da outra ponta (veja
figura). O cabo azul claro da Cisco RJ-45/DB-9 também funciona neste caso.


Conecte o cabo console na interface auxiliar do equipamento principal e depois na console do outro equipamento. Depois é necessário fazer a seguinte configuração na interface auxiliar (line aux 0).

line aux 0
modem InOut
transport preferred telnet
transport input all
transport output telnet
stopbits 1

Também é necessário que o seu roteador Cisco possua uma interface Loopback configurada para que você possa executar o comando telnet para esta interface.

interface loopback 0
ip address 10.1.1.1 255.255.255.255

Em seguida, deve-se verificar qual é o número atribuido a sua porta auxiliar. Para isso entre com o comando show line.

Router#show line
Tty Line Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int
0 0 CTY - - - - - 0 0 0/0 -
1 1 AUX 9600/9600 - inout - - - 1 0 1/1 -
*194 194 VTY - - - - - 3 0 0/0 -
195 195 VTY - - - - - 1 0 0/0 -
196 196 VTY - - - - - 0 0 0/0 -
197 197 VTY - - - - - 0 0 0/0 -
198 198 VTY - - - - - 0 0 0/0 -


As duas primeiras colunas mostram o número atribuído a interface auxiliar. Agora basta executar o comando telnet endereço 2000+line. O último parâmetro (porta) deverá ser o número da linha somado com o número 2000 - para este exemplo ficará 2001.

Router#telnet 10.1.1.1 2001
Trying 1.0.0.1, 2001 ... Open

login:


And that's all folks!

Mais informações:

segunda-feira, 30 de março de 2009

Every move you make...

Eu sempre imaginei que instalar e manter um software de gerenciamento e backup de configuração de equipamentos de rede fosse uma grande idéia. Não só para conseguir restaurar um equipamento queimado de uma forma mais rápida - já que o backup, pelo menos, existe - mas também para fazer o acompanhamento das mudanças - afinal de contas, estamos na era da Gerência de Mudanças, não?

Bom, isto foi o que aconteceu com o Nick, um leitor do ISC Diary, e que o pessoal o SANS ISC relatou tão bem. O roteador foi comprometido - com usuário padrão com senha fácil -, e logo o atacante criou um túnel para a sua origem, alterou alguns parâmetros para garantir que a porta estaria aberta da próxima vez e tudo mais. O syslog e o IDS não se manifestaram, afinal de contas, a senha era válida e o acesso era permitido... O atacante só não contava com o Rancid. Assim que o Rancid fez o backup da configuração e detectou a alteração, um e-mail foi enviado para o administrador do sistema e em pouco tempo tudo estava resolvido.

Achei interessante relatar este exemplo aqui, já que o post-tutorial que fiz há algum tempo atrás sobre o Rancid aqui neste blog é disparado o post menos visto de todos os tempos! O que me faz pensar que todos já tem suas soluções de backup e gerenciamento de configuração funcionando a todo vapor ou não temos nenhum leitor mesmo :-). Particularmente eu ficaria com a segunda opção... Você sabe qual é o software usado na sua empresa para gerenciamento e backup de configuração? Você tem uma dica? Deixe-a aí nos comentarios.

Mais informações:

quinta-feira, 20 de novembro de 2008

Cisco IP SLA

Conhecida antes da versão 12.4T como RTR (Response Time Report) e SAA (Service Assurance Agent), a ferramenta de monitoração Cisco IP SLA (Service Level Agent) é utilizada para fazer monitoração ativa de tempo de resposta via ICMP (ou utilizando outras aplicações como HTTP e DNS), jitter (inclusive jitter unidirecional), perda de pacotes, etc. diretamente em um roteador Cisco, ou seja, sem depender de um outro software ou servidor para fazer a colheta destas informações. Apesar das informações estarem disponíveis no roteador, é também interessante utilizar alguma ferramenta para gerar um gráfico, como o MRTG ou Cacti, para deixar o seu chefe ainda mais feliz! :-)

Configurando o IP SLA

Vamos ver um exemplo de configuração para medir o tempo de resposta entre dois pontos utilizando a ferramenta para medir jitter do IP SLA. Entenda dois pontos como um circuit ponto-a-ponto ou dois pontos quaisquer na Internet. Veja a configuração:

! criamos a monitoração 100 para o endereço IP 10.10.10.1
!
ip sla 100
icmp-jitter 10.10.10.1 source-ip 192.168.1.1 num-packets 20
frequency 300
!
! então é necessário ativar a monitoração recém criada
!
ip sla schedule 100 start-time now life forever

Depois de criarmos a monitoração e ativá-la, podemos verificar se está funcionando e como está o nosso tempo de resposta e perda de pacotes com o comando show ip sla statistics 100.

Router#sh ip sla statistics 100

Round Trip Time (RTT) for Index 100
Type of operation: icmpJitter
Latest RTT: 230 milliseconds
Latest operation start time: 13:04:36.499 BRST Wed Nov 26 2008
Latest operation return code: OK
RTT Values:
Number Of RTT: 13 RTT Min/Avg/Max: 325/354/413
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0
Destination to Source Latency one way Min/Avg/Max: 0/0/0
Jitter Time:
Number of SD Jitter Samples: 9
Number of DS Jitter Samples: 9
Source to Destination Jitter Min/Avg/Max: 1/5/17
Destination to Source Jitter Min/Avg/Max: 0/25/71
Packet Late Arrival: 0
Out Of Sequence: 0
Source to Destination: 0 Destination to Source 0
In both Directions: 0
Packet Skipped: 0 Packet Unprocessed: 7
Packet Loss: 0
Loss Period Length Min/Max: 0/0
Number of successes: 1
Number of failures: 0
Operation time to live: Forever

As informações que queremos observar estão destacadas em azul.

Gerando os Gráficos

Para continuar este exemplo, vamos gerar um gráfico das informações de RTT (round-trip time) máximo e mínimo. Para isso, vamos utilizar o MRTG e os OIDs:
  • rttMonLatestIcmpJitterRTTMin.XXX ou 1.3.6.1.4.1.9.9.42.1.5.4.1.4.XXX para medir o RTT mínimo da instância XXX (no nosso caso a instância 100).
  • rttMonLatestIcmpJitterRTTMax.XXX ou 1.3.6.1.4.1.9.9.42.1.5.4.1.5.XXX para medir o RTT máximo da instância XXX.
A configuração do MRTG utilizada foi:

# IP SLA 100
Target[rtt_mon_100]:1.3.6.1.4.1.9.9.42.1.5.4.1.4.100&1.3.6.1.4.1.9.9.42.1.5.4.1.5.100:community@192.168.1.1:
MaxBytes[rtt_mon_100]: 350
AbsMax[rtt_mon_100]: 2000
YLegend[rtt_mon_100]: Round Trip Time
ShortLegend[rtt_mon_100]: ms
LegendI[rtt_mon_100]: min rtt (ms):
LegendO[rtt_mon_100]: max rtt (ms):
Legend1[rtt_mon_100]: min rtt (ms)
Legend2[rtt_mon_100]: max rtt (ms)
Title[rtt_mon_100]: Tempo de Resposta - IP SLA 100


Para a monitoração que configuramos anteriormente, podemos obter um gráfico que nos mostrará o tempo de resposta mínimo (em verde) e o máximo (em azul). Deste gráfico podemos ter uma idéia de como está o jitter para um determinado circuito ou caminho.
Com esta simples monitoração é possível observar a variação do tempo de resposta com o passar do tempo (veja figura 1 no período entre 18:00 e 22:00 horas) ou ainda verificar que um determinado caminho está congestionado - com alterações no tempo de resposta, principalmente durante certos períodos (veja figura 2).

Figura 1

Figura 2

Para mais informações:

segunda-feira, 6 de outubro de 2008

Configuração de portas Gigabit Ethernet

Esta noite estava vendo um outro blog sobre redes quando encontrei uma frase ao mesmo tempo trágica e engraçada (como a frase foi escrita em inglês, manterei na língua original): "Repeat after me. I will not force a switch to 1000/Full, even if some idiot insists that I should."

Essa é, com certeza, umas das discussões mais antigas que eu já vi. Alguns dizem que sim, alguns dizem que não, enfim... Apesar do assunto ser bastante comentado em diversos lugares, como por exemplo a página Techworld, muita gente custa a acreditar! :)

Por isso o meu grande amigo Thiago Siqueira fez um ótimo dever de casa há algum tempo atrás e eu gostaria de compartilhar para também ficar registrado aqui.

Acontece que no início da implementação do padrão Gigabit Ethernet (IEEE 802.3z) a especificação não era clara a respeito de utilizar auto-negociação ou configurar manualmente a interface para half ou full-duplex em portas gigabit e isso fez com que os fabricantes - talvez utilizando o mesmo código que utilizavam para portas 10/100 ou ainda por causa do comodismo em continuar configurando um novo padrão com velhos costumes - implementassem de forma diferente o padrão Gigabit Ethernet em UTP, uma herança da forma como foi definido e implementada a auto-negociação do padrão IEEE 802.3u (Ethernet 100 MBps). Com o passar do tempo, surgiu toda essa confusão.

Para o padrão IEEE 802.3 (Ethernet) o uso de auto-negociação para interfaces 1000BASE-T é MANDATÓRIO. Consulte o documento a seguir para mais informações (página 603, item A, anexo 28A, cláusula 28D.5): http://standards.ieee.org/getieee802/download/802.3-2005_section2.pdf

Muito tempo depois a possibilidade de configuração fixa para full ou half-duplex no padrão Gigabit Ethernet foi possível (e aceitável) para que garantisse a compatibilidade entre os equipamentos que seguiam o padrão (mais novos) e os equipamentos mais velhos (do início da implementação do padrão Gigabit Ethernet). Hoje todos os fabricantes implementam corretamente (ou pelo menos deveriam implementar) o padrão estabelecido pelo IEEE em 1998.

sexta-feira, 30 de maio de 2008

Diminuindo o tempo de reboot do IOS

Na versão 12.3(2)T do IOS da Cisco foi incluída uma funcionalidade que torna possível otimizar o tempo total de reboot de um roteador. Essa nova funcionalidade é chamada de Warm Reload/Upgrade.

O grande ganho na verdade está em fazer o carregamento e a descompressão da imagem do IOS na memória RAM em paralelo com a que está sendo executada no momento. A partir daí quando é efetuado o reload, como estes passos de carregamento e descompressão já estão feitos, o tempo de reboot se limita apenas a inicialização e a execução do IOS.

Estimativas apontam para uma redução média de até 66% do tempo total de reboot, ou seja, se o reboot normal demora cerca de 3 minutos, com o Warm Reload estima-se que demore apenas 1 minuto.

Esta funcionalidade pode ser muito útil para diminuir o downtime do equipamento em situações de upgrade de IOS ou em casos de reboots espontâneos (por exemplo, por causa de um crash).

Recomendo fortemente a leitura da documentação no site da Cisco (link acima), principalmente porque este funcionalidade não deve ser utilizada muitas vezes consecutivas, pois pode causar problemas ao funcionamento do roteador (por exemplo, de fragmentação de memória).

segunda-feira, 26 de maio de 2008

BGP, route servers e afins

Para quem acompanha o blog já deve ter observado as outras dicas a respeito dos route servers. Estes são roteadores reais (ou simulados através de software), geralmente a livre disposição para acesso remoto (via telnet) para troubleshooting de problemas de anúncios de rotas BGP e alcançabilidade pela Internet.

A dica agora é para o site CiscoNet que representa e dispõe no mapa Mundi os route servers disponíveis bastando apenas um click para que se acesse o route server desejado.

Para quem deseja ir mais a fundo neste assunto há neste site muitas outras informações interessantes além do acesso aos route servers como noções e configuração de BGP, sites de whois, listas de servidores de dns entre outras.

quarta-feira, 21 de maio de 2008

Como fazer o backup das configurações do PuTTY

Para quem não conhece, o PuTTY é uma das ferramentas mais utilizadas para se realizar a administração remota a equipamentos através dos protocolos telnet, rlogin e ssh. Ele é um software pequeno e uma das grandes vantagens é que não requer a instalação local para funcionar.

No entanto, muitos usuários do PuTTY já se depararam com o problema de perder as configurações do PuTTY quando se formata ou se migra de uma máquina cliente para outra. Recriar estas configurações do PuTTY perfil a perfil (IPs dos equipamentos, portas remotas, tipo de emulação de terminal, cores do terminal, etc) pode se tornar MUITO desagradável.

O ponto chave é que o PuTTY não cria um arquivo no filesystem com as configurações de todos os perfis de acesso, mas sim estas informações ficam "escondidas" dentro do registro do Windows.

Para fazer o backup das configurações o procedimento abaixo deve ser executado:
  • Abrir o regedt32 do Windows
  • Buscar pela chave de nome "SimonTatham" que fica no caminho HKEY_CURRENT_USER\Software\SimonTatham
  • Ao localizar a chave SimonTatham pressione o botão direito do mouse e selecione a opção Exportar
  • Salve esta chave como putty.reg
  • Copie esta chave para algum dispositivo de armazenamento externo (pen drive, disco externo, etc)

Para fazer o restore das configurações é muito simples:
  • Copie o arquivo putty.reg para o micro desejado
  • Pressione o botão direito do mouse sobre o arquivo e selecione a opção Mesclar

Pronto com isso deve ser possível manter as configurações de seu PuTTY!

sexta-feira, 8 de fevereiro de 2008

Comando Reload no Cisco IOS

Perder a comunicação com um roteador (neste caso, um Cisco rodando IOS) não é a melhor coisa que pode acontecer na vida, principalmente se você estiver trabalhando em alguma hora da madrugada de domingo e o equipamento está em outro prédio, cidade ou país... Atualmente (e infelizmente) não existe no Cisco uma interface de commit-rollback de configuração como existe no JunOS da Juniper. No entanto, é possível utilizar o comando reload para programar um reload com tempo hábil para aplicar as configurações e cancelar o reload - ou no pior dos casos, aguardar o processo de boot do IOS novamente com a configuração antiga. Antes de inicar o procedimento abaixo é importante salvar a configuração do roteador.

1. Programe seu reload para daqui 3 minutos:

MyRouter#reload in 3
Reload scheduled in 3 minutes
Proceed with reload? [confirm]y
2. Aplique as configurações (por exemplo, acertar uma ACL):
MyRouter#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
MyRouter(config)#interface serial0
MyRouter(config-if)#ip access-group 110 in
MyRouter(config-if)#^Z
MyRouter#
3. Cancele o reload caso tudo esteja funcionando como esperado:
MyRouter#reload cancel

sexta-feira, 17 de agosto de 2007

Rancid e Fortinet

Para aqueles que como eu necessitam fazer backup da configuração de equipamentos da Fortinet, Daniel Epstein (thanks Daniel!!!) publicou na lista oficial do Rancid um patch para ser aplicado no Rancid para que o mesmo possa fazer backups dos Fortigate Firewalls rodando FortiOS 2.8 e 3.0.

Basicamente é utilizado os scripts do Netscreen (nlogin) para criar novos scripts para o Fortinet (fnlogin). Também precisei instalar a versão de desenvolvimento do Rancid (versão rancid-2.3.2a6) que foi testada no Debian pelo próprio Daniel e por mim no FreeBSD (instalando o Rancid via ports rancid-devel e depois aplicando o patch).

O Rancid, para aqueles que ainda não conhecem esta ferramenta, é um software para fazer backup e controle de configuração de equipamentos de rede que funciona com equipamentos dos principais fabricantes, dentre eles Cisco, Juniper, Extreme, Alteon, Force10, etc. Para saber mais, basta conferir o tutorial detalhado de como instalar e configurar o Rancid.

terça-feira, 17 de julho de 2007

Cisco Replace e Rollback

A partir da versão 12.3(7)T ou 12.2(25)S não é necessário fazer todo o processo de boot para reverter para a configuração que está gravada na startup-config, basta utilizar a feature "Configuration Replace and Configuration Rollback". A idéia é muito simples: se houver algum problema enquanto estivermos aplicando as novas configurações, é possível reverter a configuração para, por exemplo, aquela que está salva na nvram. É possível também salvar várias versões de uma configuração e carregá-las quando for necessário. Primeiramente, vamos ver um exemplo:

cisco# configure terminal
cisco(config)#interface loopback 0
cisco(config-if)#ip address 10.10.10.10 255.255.255.255
Se não foi satisfatória essa alteração, então podemos carregar novamente a configuração que está gravada na startup-config diretamente para a running-config.
cisco#configure replace nvram:startup-config list
This will apply all necessary additions and deletions
to replace the current running configuration with the
contents of the specified configuration file, which is
assumed to be a complete configuration, not a partial
configuration. Enter Y if you are sure you want to proceed. ? [no]: yes
!Pass 1

!List of Commands:
no interface Loopback0
end


Total number of passes: 1
Rollback Done
cisco#
Até agora, nenhuma novidade. No entanto, podemos combinar o configure replace com o archive, ou seja, podemos armazenar várias versões diferentes de configuração e utilizá-las com o configure replace.
cisco(config)#archive
cisco(config-archive)#maximum 5
cisco(config-archive)#path flash:myconfig
Ou seja, agora podemos ter 5 arquivos de backup que serão gravados na memória flash com o prefixo "myconfig".
cisco#archive config

cisco#sh archive
There are currently 2 archive configurations saved.
The next archive file will be named flash:myconfig-2
Archive # Name
0
1 flash:myconfig-1 <- Most Recent
2
3
4
5
(...)

Agora podemos utilizar o comando "archive config" para gravar e "configure replace" para carregar versões de configuração.
cisco#configure replace flash:myconfig-1 list time 120
This will apply all necessary additions and deletions
to replace the current running configuration with the
contents of the specified configuration file, which is
assumed to be a complete configuration, not a partial
configuration. Enter Y if you are sure you want to proceed. ? [no]: yes
!Pass 1

!List of Commands:
no interface Loopback0
end


Total number of passes: 1
Rollback Done

cisco# configure confirm
Neste último exemplo, utilizamos a opção time no comando configure replace para que se não houver a confirmação (configure confirm) então o IOS irá reverter automaticamente para a última configuração antes do replace após transcorridos 2 minutos (120 segundos).

terça-feira, 23 de janeiro de 2007

Looking Glass

Looking glass é uma ferramenta que permite efetuar consultas sobre tabelas de roteamento (protocolo BGP) e testes de ping e traceroute. Ela é muito útil para que os administradores de rede possam obter uma visão externa de como estão sendo propagados os anúncios dos seus blocos CIDR na Internet.

A grande maioria dos looking glasses são de acesso gratuito e são implementados através de uma interface web, mas também é possível encontrar quem disponibilize o acesso direto a um roteador (real ou virtual) em que se pode conectar através de telnet. Em ambos os casos os comandos que podem ser efetuados são limitados para evitar problemas de segurança.

Segue a lista de looking glasses que costumo consultar:


GlobalCrossing - telnet://route-server.gblx.net
GlobalCrossing - http://www.globalcrossing.com/network/network_looking_glass.aspx

Host.net - telnet://route-server.host.net
Hurricane Electric - http://lg.he.net/
iPivot - http://lg.ipivot.net.br/
iVeloz - http://lg.iveloz.net.br/
Maxiweb - http://lg.maxiweb.com.br/cgi-local/lg.cgi
NetBotanic - http://lg.netbotanic.com.br/lg.php
NTT - http://www.us.ntt.net/support/looking-glass/
PCH - https://prefix.pch.net/applications/lg/

PTTMetro-RJ - telnet://lg.rj.ptt.br
PTTMetro-SP - telnet://lg.sp.ptt.br
RedIRIS - http://www.rediris.es/red/lg/
RNP - https://memoria.rnp.br/ip/lg.php
Savvis - http://as3561lg.savvis.net/lg.html
Seabone - https://gambadilegno.noc.seabone.net/lg/
SUNET - http://stats.sunet.se/looking-glass/lg.cgi
SouthTech Telecom - http://bgp.stech.net.br/lg
Sprint - https://www.sprint.net/lg/lg_start.php
Telefônica TIWS https://www.globalsolutions.telefonica.com/en/wholesale/looking-glass/
Unifique - http://asn28343.net.br/
Zayo - http://lg.zayo.com/lg.cgi

sábado, 20 de janeiro de 2007

Whois centralizado

O time da Cymru (http://www.cymru.com/) está disponibilizando gratuitamente no link abaixo uma ferramenta de whois centralizado que vai facilitar em muito as identificações de AS numbers de origem. As informações são atualizadas de 4 em 4 horas o que confere grande credibilidade as informações divulgadas e o mais interessante é que ele permite mostrar também as informações das entidades que um determinado AS faz peering.

https://asn.cymru.com/cgi-bin/whois.cgi

Maiores informações de como utilizar as ferramentas podem ser encontradas em:

http://www.cymru.com/BGP/asnlookup.html

Gerenciando a alocação de endereços IP

Para quem procura uma ferramenta free para o gerenciamento e alocação de blocos IP, recomendo o NorthStar. Ele é bem simples de utilizar e é escrito em PERL, o que indica que pode ser portado sem maiores problemas para a grande maioria das plataformas.

Para quem se interessar existe um demo online para avaliação da ferramenta (mas infelizmente nem sempre está no ar :P ). Por isso, instalem!