Portanto, em modo de configuração:
Router(config)#line vty 0 15
Router(config-line)#escape-character 3
Router(config)#line con 0
Router(config-line)#escape-character 3
segunda-feira, 23 de fevereiro de 2009
Cancelando com CTRL+C no Cisco
Sempre tive problemas no meu Ubuntu, utilizando o Terminal, para cancelar um traceroute ou um ping quando conectado em um equipamento Cisco. Mas, meus problemas acabaram. E compartilho com vocês do blog. Graças a um comentário na lista da Nanog descobri que, utilizando o comando escape-character 3 dentro dos line vty e do line con, você pode utilizar simplesmente CTRL+C para cancelar o comando.
Portanto, em modo de configuração:
Portanto, em modo de configuração:
sexta-feira, 20 de fevereiro de 2009
Um roteador, dois provedores e alguma redundância
De tempos em tempos surge em alguma lista ou forum de discussão a questão de como ter redundância entre dois provedores de forma automática no meu escritório? E essa foi exatamente a questão que foi feita no forum do blog Cisco Certified. É claro que existem soluções proprietárias (o Radware Linkproof, por exemplo) ou open-source para a solução deste problema, mas a solução que vou explicar aqui é toda baseada em um único roteador Cisco recebendo dois links de provedores diferentes (leia-se: com endereçamento válido diferente).
O cenário que iremos tratar neste post é o seguinte:
Neste cenário, o roteador Router está conectado ao ISP 1 e ao ISP 2 através de links ponto-a-ponto e o endereçamento válido que o cliente deverá usar é o mesmo do link. Na rede interna do cliente não existe nenhum servidor (pelo menos para este exemplo). Só existem conexões do escritório (redes 192.168.0.0/24 e 172.16.0.0/24) para a Internet. Neste exemplo também estou considerando que a rede 192.168.0.0/24 irá utilizar o ISP 2 e a rede 172.16.0.0/24 o ISP 1 (devido à política interna, uma rede tem prioridade sobre a outra, etc). Estas redes podem ou não estar diretamente conectadas no roteador Router.
É claro que colocar uma rota default apontando para um ou outro provedor (ISP) não será a nossa solução e, para este caso, quando não podemos utilizar um protocolo de roteamento dinâmico, vamos utilizar duas features da Cisco: o Cisco IP SLA (que já foi tratado neste post) e o Policy-Based Routing (que também já foi tratado neste outro post).
O primeiro passo é configurar uma monitoração com o IP SLA e começar a fazer o tracking desta monitoração. Para isso utilizaremos o Object Tracking.
Para verificar que o tracking está funcionando, utilize o comando show track.
Como estamos preocupados com o tempo de convergência da rede na ocasião de uma falha, configurei o intervalo de testes do IP SLA para 5 segundos. Agora iremos utilizar o tracking que configuramos no passo anterior em um route-map que verificará se o default gateway está respondendo ou não, para então utilizar somente aquele que estiver respondendo.
Como podemos observar (pelo menos em nosso teste) o host 172.16.0.1 utilizará o ISP 1 (next-hop 10.1.1.2) preferencialmente e o host 192.168.0.1 utilizará o outro ISP. Agora podemos verificar como está o nosso route-map.
O último passo é configurar o NAT nas interfaces utilizando um route-map para identificar qual é a interface que está sendo utilizada como saída. Dessa forma, quando um determinado pacote for utilizar o link do ISP 1 para acessar a Internet, o NAT irá traduzir para o endereço da interface correspondente (dado que estamos utilizando interface overload na configuração do NAT).
Neste momento, podemos fazer a primeira verificação. Como exemplo, estou utilizando um roteador com endereço IP 192.168.0.1 e 172.16.0.1 para fazer os testes.
Este host está conectado na interface fastethernet0/0 do roteador Router. Podemos verificar também que a tabela de NAT está mostrando as traduções para os dois links separadamente.
Observe que a primeira linha de traduções mostra a tradução para o endereço 10.1.1.1 (que é o endereço do ISP 1 e a segunda linha mostra a tradução para o endereço do ISP 2: 10.1.2.1. Vamos agora simular a falha do ISP 2 e ver o que acontece com a tabela de traduções e os pings.
Aproximadamente cinco segundos após desligar o link para o ISP 2, podemos observar que o tracking não está mais funcionando para o endereço 10.1.2.2 - assim como o nosso route-map -, e a tabela de NAT mostra que agora estamos traduzindo todos os endereços para 10.1.1.1 (que é o endereço do ISP 1).
Lembre-se sempre que este é um exemplo e que para ser aplicado em um ambiente real devem ser feitos alguns ajustes.
Mais informações em:
O cenário que iremos tratar neste post é o seguinte:
Neste cenário, o roteador Router está conectado ao ISP 1 e ao ISP 2 através de links ponto-a-ponto e o endereçamento válido que o cliente deverá usar é o mesmo do link. Na rede interna do cliente não existe nenhum servidor (pelo menos para este exemplo). Só existem conexões do escritório (redes 192.168.0.0/24 e 172.16.0.0/24) para a Internet. Neste exemplo também estou considerando que a rede 192.168.0.0/24 irá utilizar o ISP 2 e a rede 172.16.0.0/24 o ISP 1 (devido à política interna, uma rede tem prioridade sobre a outra, etc). Estas redes podem ou não estar diretamente conectadas no roteador Router.É claro que colocar uma rota default apontando para um ou outro provedor (ISP) não será a nossa solução e, para este caso, quando não podemos utilizar um protocolo de roteamento dinâmico, vamos utilizar duas features da Cisco: o Cisco IP SLA (que já foi tratado neste post) e o Policy-Based Routing (que também já foi tratado neste outro post).
O primeiro passo é configurar uma monitoração com o IP SLA e começar a fazer o tracking desta monitoração. Para isso utilizaremos o Object Tracking.
ip sla monitor 1
type echo protocol ipicmpecho 10.1.1.2
frequency 5
ip sla monitor schedule 1 start-time now life forever
ip sla monitor 2
type echo protocol ipicmpecho 10.1.2.2
frequency 5
ip sla monitor schedule 2 start-time now life forever
track 123 rtr 1 reachability
track 124 rtr 2 reachability
Para verificar que o tracking está funcionando, utilize o comando show track.
Router#show track
Track 123
Response Time Reporter 1 reachability
Reachability is Up
1 change, last change 00:00:05
Latest operation return code: OK
Latest RTT (millisecs) 168
Track 124
Response Time Reporter 2 reachability
Reachability is Up
1 change, last change 00:00:04
Latest operation return code: OK
Latest RTT (millisecs) 124
Como estamos preocupados com o tempo de convergência da rede na ocasião de uma falha, configurei o intervalo de testes do IP SLA para 5 segundos. Agora iremos utilizar o tracking que configuramos no passo anterior em um route-map que verificará se o default gateway está respondendo ou não, para então utilizar somente aquele que estiver respondendo.
access-list 11 permit host 172.16.0.1
access-list 12 permit host 192.168.0.1
route-map in-out-link-1 permit 10
match ip address 11
set ip next-hop verify-availability 10.1.1.2 10 track 123
set ip next-hop verify-availability 10.1.2.2 20 track 124
route-map in-out-link-1 permit 20
match ip address 12
set ip next-hop verify-availability 10.1.2.2 10 track 124
set ip next-hop verify-availability 10.1.1.2 20 track 123
Como podemos observar (pelo menos em nosso teste) o host 172.16.0.1 utilizará o ISP 1 (next-hop 10.1.1.2) preferencialmente e o host 192.168.0.1 utilizará o outro ISP. Agora podemos verificar como está o nosso route-map.
Router#show route-map in-out-link-1
route-map in-out-link-1, permit, sequence 10
Match clauses:
ip address (access-lists): 11
Set clauses:
ip next-hop verify-availability 10.1.1.2 10 track 123 [up]
ip next-hop verify-availability 10.1.2.2 20 track 124 [up]
Policy routing matches: 0 packets, 0 bytes
route-map in-out-link-1, permit, sequence 20
Match clauses:
ip address (access-lists): 12
Set clauses:
ip next-hop verify-availability 10.1.2.2 10 track 124 [up]
ip next-hop verify-availability 10.1.1.2 20 track 123 [up]
Policy routing matches: 0 packets, 0 bytes
O último passo é configurar o NAT nas interfaces utilizando um route-map para identificar qual é a interface que está sendo utilizada como saída. Dessa forma, quando um determinado pacote for utilizar o link do ISP 1 para acessar a Internet, o NAT irá traduzir para o endereço da interface correspondente (dado que estamos utilizando interface overload na configuração do NAT).
interface fa0/0
ip nat inside
! devemos aplicar o route-map in-out-link-1 na interface conectada na rede
! interna para fazer com que o roteador não utilize a tabela de rotas padrão.
ip policy route-map in-out-link-1
int atm1/0.1
ip nat outside
interface atm2/0.1
ip nat outside
route-map nat-1 permit 10
match interface ATM1/0.1
!
route-map nat-2 permit 10
match interface ATM2/0.1
!
ip nat inside source route-map nat-1 interface atm 1/0.1
ip nat inside source route-map nat-2 interface atm 2/0.1
Neste momento, podemos fazer a primeira verificação. Como exemplo, estou utilizando um roteador com endereço IP 192.168.0.1 e 172.16.0.1 para fazer os testes.
Host#ping 1.1.1.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/295/760 ms
Host#ping 1.1.1.1 source lo1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 96/187/304 ms
Este host está conectado na interface fastethernet0/0 do roteador Router. Podemos verificar também que a tabela de NAT está mostrando as traduções para os dois links separadamente.
Router#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 10.1.1.1:116 172.16.0.1:116 1.1.1.1:116 1.1.1.1:116
icmp 10.1.2.1:117 192.168.0.1:117 1.1.1.1:117 1.1.1.1:117
Observe que a primeira linha de traduções mostra a tradução para o endereço 10.1.1.1 (que é o endereço do ISP 1 e a segunda linha mostra a tradução para o endereço do ISP 2: 10.1.2.1. Vamos agora simular a falha do ISP 2 e ver o que acontece com a tabela de traduções e os pings.
Router#show track
Track 123
Response Time Reporter 1 reachability
Reachability is Up
1 change, last change 00:02:45
Latest operation return code: OK
Latest RTT (millisecs) 79
Tracked by:
ROUTE-MAP 0
Track 124
Response Time Reporter 2 reachability
Reachability is Down
2 changes, last change 00:00:00
Latest operation return code: Timeout
Tracked by:
ROUTE-MAP 0
Router#show route-map in-out-link-1
route-map in-out-link-1, permit, sequence 10
Match clauses:
ip address (access-lists): 11
Set clauses:
ip next-hop verify-availability 10.1.1.2 10 track 123 [up]
ip next-hop verify-availability 10.1.2.2 20 track 124 [down]
Policy routing matches: 0 packets, 0 bytes
route-map in-out-link-1, permit, sequence 20
Match clauses:
ip address (access-lists): 12
Set clauses:
ip next-hop verify-availability 10.1.2.2 10 track 124 [down]
ip next-hop verify-availability 10.1.1.2 20 track 123 [up]
Policy routing matches: 0 packets, 0 bytes
Router#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 10.1.1.1:119 172.16.0.1:119 32.1.1.1:119 32.1.1.1:119
icmp 10.1.1.1:118 192.168.0.1:118 32.1.1.1:118 32.1.1.1:118
Aproximadamente cinco segundos após desligar o link para o ISP 2, podemos observar que o tracking não está mais funcionando para o endereço 10.1.2.2 - assim como o nosso route-map -, e a tabela de NAT mostra que agora estamos traduzindo todos os endereços para 10.1.1.1 (que é o endereço do ISP 1).
Lembre-se sempre que este é um exemplo e que para ser aplicado em um ambiente real devem ser feitos alguns ajustes.
Mais informações em:
terça-feira, 17 de fevereiro de 2009
Atualizar Horário de Verão - Juniper M7i 9.1 ou maior
Estava com dificuldades para configurar o horário de verão em um Juniper M7i com JunOS acima de 9.1. Conectei no shell e vi que existia o zic e o zdump. Pensei: se a base é BSD e tenho essas duas ferramentas, por que não fazer igual no próprio FreeBSD?
Tentei e funcionou. E, não é solução de contorno. Achei depois de ter feito um documento na Knowledge Base da Juniper que corrobora a solução.
Entre na shell do Juniper após conectado:
>start shell
Entre no modo superusuário:
#su -
#vi ZONA.zic
Dentro do arquivo, para o caso do horário de verão 2008/2009 (que agora é fixo e, portanto, você pode fazer para todos os anos seguindo as regras), coloque:
Rule Brazil 2008 only - Oct 19 00:00 1 S
Rule Brazil 2009 only - Feb 15 00:00 0 -
Zone ZONA -3:00 Brazil BR%sT
O nome ZONA é o que aparecerá depois na CLI para seleção do seu horário de verão personalizado. Coloque o nome que preferir.
Como referência, indico o site da RNP que sempre coloca o modo de fazer esse tipo de atualização nos sistemas operacionais mais comuns.
Após salva o arquivo, saia e, de volta ao shell em modo root, execute:
#/usr/libexec/ui/compile-tz ZONA.zic
Saia do modo shell e volte para a CLI. Lá, informe ao Juniper que você quer usar a base personalizada de time-zone, e não a padrão:
>set system use-imported-time-zones
Agora, configure seu timezone, escolhendo a zona ZONA:
>set system time-zone ZONA
Salve as configurações e confira com um "show system uptime" se tudo está certo.
Se você tem acesso ao KB da Juniper, clique aqui e acesse o documento que mostra quase isso, que você só vê mastigado aqui no Nexthop.