quinta-feira, 10 de janeiro de 2013

Rotas Flutuantes no Ambiente Corporativo

Olá Pessoal.

Hoje recebi um e-mail de um aluno com um problema comumente encontrado em empresas e achei por bem que seria interessante compartilhar a solução com todos, já que essa é uma dúvida recorrente! O e-mail apresentava a seguinte situação:

"
Brito, Bom Dia.

Veja se você consegue me dar uma luz. Em um Switch-Core chegam dois links, um MPLS e outro LAN-2-LAN (Clear Channel). O link MPLS é o principal, com isso colocamos uma rota default apontando para ele no SW-Core, só que quando o link principal cai, por ter uma rota default para ele, o link LAN-2-LAN não assume o tráfego. Para o link LAN-2-LAN assumir o tráfego temos que tirar a rota default para o link principal (manualmente). Tem alguma maneira de automatizar a retirada da rota quando o link principal cair?

Desde já agradeço.

E a resposta é: Sim, a solução existe e não é muito complicada. Antes de discutir a solução do problema, vamos visualizar uma imagem simplificada do cenário. A interface f0/0 está conectada na rede local, a interface f1/0 recebe o link MPLS e a interface f2/0 recebe o link LAN-2-LAN:



A princípio, uma solução imediata para o problema seria adicionar duas rotas default com custos diferentes, uma saindo por cada interface:

SW-Core(config)# ip route 0.0.0.0 0.0.0.0 f1/0 1
SW-Core(config)# ip route 0.0.0.0 0.0.0.0 f2/0 2

Mas isso não funcionaria! O problema dessa "solução" é que os links MPLS e LAN-2-LAN são diretamente conectados ao Switch-Core através de interfaces fast-ethernet e, por isso, quando o link cai, a interface mantém seu status como up. Então para resolver o problema é necessário monitorar a alcançabilidade IP via "track" com "IP SLA". A solução consiste nas seguintes etapas:

1) Criar o seguinte monitoramento ao gateway MPLS:

SW-Core(config)# ip sla monitor 1
SW-Core(config-sla-monitor)# type echo protocol ipIcmpEcho 11.11.11.1 source-interface f1/0
SW-Core(config-sla-monitor)# timeout 500
SW-Core(config-sla-monitor)# frequency 3
SW-Core(config-sla-monitor)# exit
SW-Core(config)# ip sla monitor schedule 1 life forever start-time now


Agora o dispositivo fará 3 tentativas de ping (echo requests) de meio em meio segundo (500ms) para o seu gateway da interface f1/0 (o link MPLS). Lembrei o aluno para não esquecer de substituir o ip 11.11.11.1 pelo endereço do gateway MPLS que eles possuem na empresa. 

Também disse ao aluno para ter em mente que essa estratégia vai consumir mais recursos do SW-Core porque ativamos um monitoramento que irá gerar tráfego com frequência para monitorar a alcançabilidade do destino. No entanto, não há outra forma de conseguir esse resultado já que a interface fast-ethernet não cai com a ausência de conectividade do link.

2) Criar um objeto de rastreabilidade (track) associado ao "SLA Monitor 1":

SW-Core(config)# track 1 rtr 1

Obs.: Em versões mais recentes do IOS pode ser que você tenha que substituir esse comando por: "track 1 ip sla 1 reachability". O recurso SLA já foi previamente denominado SAA e RTR, daí a menção rtr no comando.

3) Criar as seguintes rotas default rastreando o link primário:

SW-Core(config)# ip route 0.0.0.0 0.0.0.0 f1/0 track 1 1
SW-Core(config)# ip route 0.0.0.0 0.0.0.0 f2/0 2


Pronto! Assim vai funcionar independente do status da interface porque o dispositivo irá monitorar o sucesso do ping ao gateway na camada 3!!! Apenas para confirmar que a solução funciona, vamos visualizar a tabela de roteamento e o objeto "track 1" do SW-Core quando o link MPLS está ativo:

SW-Core#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     22.0.0.0/30 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, FastEthernet2/0
     11.0.0.0/30 is subnetted, 1 subnets
C       11.11.11.0 is directly connected, FastEthernet1/0
C    192.168.0.0/24 is directly connected, FastEthernet0/0
S*   0.0.0.0/0 is directly connected, FastEthernet1/0
SW-Core#
SW-Core#show track 1
Track 1
  Response Time Reporter 1 state
  State is Up
    2 changes, last change 00:00:59
  Latest operation return code: OK
  Latest RTT (millisecs) 16
  Tracked by:
    STATIC-IP-ROUTING 0

Reparem que a rota default sai pela interface f1/0 do link MPLS. Também repare que o objeto "track 1" está com status UP. Agora vou simular uma queda no link MPLS derrubando a interface do roteador que representa a operadora e vajamos o resultado:

SW-Core#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     22.0.0.0/30 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, FastEthernet2/0
     11.0.0.0/30 is subnetted, 1 subnets
C       11.11.11.0 is directly connected, FastEthernet1/0
C    192.168.0.0/24 is directly connected, FastEthernet0/0
S*   0.0.0.0/0 is directly connected, FastEthernet2/0
SW-Core#
SW-Core#show track 1
Track 1
  Response Time Reporter 1 state
  State is Down
    3 changes, last change 00:00:09
  Latest operation return code: Timeout
  Tracked by:
    STATIC-IP-ROUTING 0

Problema resolvido!
Espero que essa postagem seja útil também para outras pessoas! ;-)
 

Abraço.

Samuel.

13 comentários:

  1. Um detalhe que não fazia parte do post (mas provavelmente necessário) diz respeito à tradução via NAT. Para fazer a tradução do NAT por meio da interface correta dependendo do link ativo, caímos na necessidade de uma estrutura condicional (se-senão) e esse tipo de situação deve ser resolvido via route-maps. No caso do cenário abordado nessa postagem a tradução ficaria:

    01. SW-Core(config)# int f0/0
    02. SW-Core(config-if)# ip nat inside
    03. SW-Core(config-if)# int f1/0
    04. SW-Core(config-if)# ip nat outside
    05. SW-Core(config-if)# int f2/0
    06. SW-Core(config-if)# ip nat outside
    07. SW-Core(config-if)# exit
    08. SW-Core(config)# access-list 1 permit 192.168.0.0 0.0.0.255
    09. SW-Core(config)# route-map MPLS permit 10
    10. SW-Core(config-route-map)# match ip address 1
    11. SW-Core(config-route-map)# match interface f1/0
    12. SW-Core(config-route-map)# exit
    13. SW-Core(config)# route-map LtoL permit 10
    14. SW-Core(config-route-map)# match ip address 1
    15. SW-Core(config-route-map)# match interface f2/0
    16. SW-Core(config-route-map)# exit
    17. SW-Core(config)# ip nat inside source route-map MPLS interface f1/0 overload
    18. SW-Core(config)# ip nat inside source route-map LtoL interface f2/0 overload

    O objetivo do post não é tratar NAT e o leitor pode encontrar mais detalhes sobre esse assunto no Lab10 do livro. Nas linhas de 01 a 06 simplesmente temos as definições das zonas inside e outside do NAT. Na linha 08 criamos uma ACL que irá definir a LAN a ser traduzida, assim como fazemos com o NAT tradicional (vide Lab10). A diferença principal é que agora criamos duas route-maps para detectar por qual link irá ocorrer a tradução e então configuramos o NAT nas linhas 17 e 18 referenciando essas route-maps.

    A lógica é a seguinte: Se a tabela de roteamento direcionou a saída do tráfego da LAN pela interface f1/0 (MPLS), então faça a tradução por essa interface. Senão, se a tabela de roteamento direcionou a saída de tráfego pela interface f2/0 (LtoL), então faça a tradução por essa interface. Caso contrário, não haverá tradução! Somente uma dessas traduções irá gerar uma correspondência e a tradução sempre ocorrerá pelo link ativo.

    ResponderExcluir
  2. Boa tarde Samuel,

    Como eu posso utilizar este recurso do IP SLA para monitorar um IP,
    e na falha do ping, acionar um track para decrementar a prioridade
    HSRP de um router ACTIVATE? Na verdade, como ficariam as linhas de configuração?

    Abraço.

    ResponderExcluir
    Respostas
    1. Olá Diego.

      Você deve repetir exatamente as mesmas instruções da primeira e segunda etapas desse artigo para criar o monitoramento e o objeto de rastreabilidade. Feito isso, na configuração das interfaces que serão membros do grupo virtual HSRP basta utilizar o comando "standby track" associado ao objeto criado (ao invés de associar com uma interface física), por ex.:

      Router(config-if)# standby 1 track 1 decrement 10

      Abraço!

      Excluir
  3. Temos isto aqui configurado em nosso Ambiente e funciona muito bem por sinal. É uma boa solução quando não se tem um balanceador de carga, porém sua administração fica mais complexa dependendo do tamanho de seu ambiente. Fazemos esse load-balance para dois links de Internet e também fazemos o load-balance por sub-net utilizando ACL. Muito bom. Parabéns pelo Tópico!

    ResponderExcluir
  4. Boa tarde Samuel.
    Excelente post, reproduzi esse lab no GNS3 e funcionou perfeitamente, exite um ambiente que gerencio na empresa,mas estou com uma duvida e desconheço como executar e gostaria da sua ajuda, ao invés de utilizar rota estática estou usando o protocolo BGP em conjunto com o HSRP em 2 cores.
    Gostaria que quando o protocolo bgp ficasse down, ai sim ocorresse a comutação automática para o roteador backup via hsrp, é possivel ?
    Como deverei configurar o track do ip sla monitor para monitorar o BGP ?
    Uma vez que o link da operadora é entregue em uma interface g0/1, então verifiquei que quando o cai somente o bgp o peer da opera continuara respondendo ao ping, onde causara a indisponibilidade,mas não ativara o hsrp.

    ResponderExcluir
    Respostas
    1. O link abaixo deve ajudá-lo, recomendo a leitura:

      http://goo.gl/OmZpmE

      Excluir
    2. Boa tarde Santos.
      fiquei contente de saber que reproduziste este Lab no GNS3. Poderia envia-me o ficheiro de configuração?
      Email:nembenemse@gmail.com

      Excluir
    3. Trata-se do laboratório 19 do meu livro, disponível para download aqui: labcisco-2ed-lab19.zip

      Excluir
  5. Já testei e usei algumas vezes essa feature e funciona muito bem, no route map, nada mais é que um PBR, muito bom o post Samuel!

    ResponderExcluir
  6. Na verdade faltaria o comando set ip next-hop verify-availability x.x.x.x 1 track 1

    ResponderExcluir
  7. Olá Samuel, por que as interfaces continuam up quando á queda no link? Não entendi a sua colocação, é pelo fato de estarem operando em interfaces Fast Ethernet apenas ?

    ResponderExcluir
    Respostas
    1. Como os links são conectados no switch core (ou num roteador que recebe as conexões dos roteadores dos links das operadoras), a queda da conexão no lado da operadora (conectividade IP) não implica em queda da conexão física (ethernet). Por isso é necessário no monitorar algum IP no lado da operadora ou mesmo na Internet para ter certeza do problema de conectividade.

      O status da interface do dispositivo só ficará com status down em caso de eventual queda na conexão física entre os equipamentos da operadora e da empresa.

      Excluir