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.

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:

8 comentários:

Cledir disse...

Cara, Parabéns!!!
Seu blog é muito bom, somente matérias interessantes de excelente conteúdo!

Vinicius Ramos disse...

Muito bom.

Parabéns.

Clayton disse...

Gustavo, tenho uma dúvida primaria, mudaria alguma coisa na configuração se esse dois provedores entregassem o links em ethernet?

Gustavo Rodrigues Ramos disse...

Não muda nada. Pode ser serial, ethernet ou ATM. Quem vai verificar se a comunicação está OK é o IP SLA. Veja que a abordagem apresentada neste tópico é diferente de configurar uma rota apontando para umaa interface e esperar essa interface cair...

Abraços,
Gustavo.

Anônimo disse...

Gustavo, tentei fazer utilizando um router 3620 no Dinamips e não consegui executar o comando ip sla monitor.
Este recurso está disponível a partir da IOS 12.1?

Gustavo Rodrigues Ramos disse...

O ip sla só está disponível a partir da versão 12.4T. Antes desta versão a Cisco possuia a mesma feature com outro nome RTR - Response Time Report, mas não me lembro exatamente quando esta feature foi adicionada ao IOS...

Moises Medeiros disse...

pode me ajudar a fazer uma redundancia neste caso:
ip dhcp pool mypool

network 192.168.2.0 255.255.255.0

domain-name gigashopping.com.br

dns-server 200.153.0.68

default-router 192.168.2.1

!

ip name-server 200.153.0.68

ip name-server xxx.xxx.xxx.xxx



interface FastEthernet0/0

ip address xxx.xxx.xxx.193 255.255.255.248 secondary

ip address xxx.xxx.xxx.1 255.255.255.0

ip nat inside

speed auto

full-duplex

!

interface Serial1/0

ip address xxx.xxx.xxx.38 255.255.255.252

ip nat outside

!

interface Serial1/1

no ip address

shutdown

!

ip nat inside source list 1 interface Serial1/0 overload

ip classless

ip route 0.0.0.0 0.0.0.0 Serial1/0

ip route xxx.xxx.xxx.192 255.255.255.248 Serial1/0

ip route 192.168.2.0 255.255.255.0 Serial1/0

no ip http server

!

access-list 1 permit 192.168.2.0 0.0.0.255


adicionando mais um ip de wan na serial 1/1

Wesley disse...

Parabéns !! Este post foi de muita ajuda , porem tenho um cenario um pouco diferente e surgiu algumas duvidas :

- o pq no Nat ?
- se tenho um ip válido na fast no router e invalidos em duas eth ligadas as operadoras como seria ?