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:
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":
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
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
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
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.
Abraço.
Samuel.
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:
ResponderExcluir01. 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.
Boa tarde Samuel,
ResponderExcluirComo 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.
Olá Diego.
ExcluirVocê 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!
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!
ResponderExcluirBoa tarde Samuel.
ResponderExcluirExcelente 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.
O link abaixo deve ajudá-lo, recomendo a leitura:
Excluirhttp://goo.gl/OmZpmE
Boa tarde Santos.
Excluirfiquei contente de saber que reproduziste este Lab no GNS3. Poderia envia-me o ficheiro de configuração?
Email:nembenemse@gmail.com
Trata-se do laboratório 19 do meu livro, disponível para download aqui: labcisco-2ed-lab19.zip
ExcluirObrigado pela dica.
ResponderExcluirJá testei e usei algumas vezes essa feature e funciona muito bem, no route map, nada mais é que um PBR, muito bom o post Samuel!
ResponderExcluirNa verdade faltaria o comando set ip next-hop verify-availability x.x.x.x 1 track 1
ResponderExcluirOlá 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 ?
ResponderExcluirComo 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.
ExcluirO 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.