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:

• Using Object Tracking with Cisco Policy-based Routing.