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.
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:
