Durante os estudos para determinadas certificações é comum seguirmos tópico a tópico focando apenas nos assuntos abordados. Contudo, a rede do mundo real não funciona assim, muito pelo contrário, buscamos sempre junção de protocolos com o intuito de entregar uma rede resiliente, segura e de fácil diagnóstico de falhas caso ocorram. Nesse artigo tentarei trazer uma abordagem prática onde iremos utilizar o Hot Standby Router Protocol (HSRP), IPSLA e Embedded Event Manager (EEM) para termos uma visão prática do que podemos prover de solução com esses protocolos juntos. Começarei com uma introdução e configuração do HSRP para em seguida utilizarmos um cenário hipotético para utilização do exemplo prático.
Hot Standby Protocol (HSRP): O protocolo HSRP fornece redundância de roteamento para hosts de uma rede ethernet que possuam rota default configurada. Para realizar essa proteção o protocolo precisa de no mínimo dois devices sendo um operando em modo active e outro em modo standby.
- Active router: O router com a maior priority (default 100) será escolhido como o active router. Em caso de empate da priority o router com o maior IP address no grupo assume como active.
- Standby router: Quando o router opera em modo standby ele aguarda até que ocorra uma falha com o active router para que assuma o posto e comece a realizar o encaminhamento de tráfego.
O funcionamento do HSRP é relativamente simples, quando ativo em um segmento de rede toda interface habilitada no mesmo grupo HSRP terá um endereço IP e MAC, ambos virtuais, que será utilizado como gateway do host. Mesmo tendo o mesmo IP virtual configurado no active e standby routers, apenas o active recebe os pacotes destinados a esse endereço IP.
Para detecção de falhas cada interface do mesmo grupo envia e recebe multicast hello messages baseadas no protocolo UDP, caso o standby router não receba essa mensagem ele entende que o active router ficou inoperante e assume como active do segmento. Toda essa transição de standby para active é transparente para os hosts do seguimento pois o MAC address move juntamente com o IP virtual.
A tabela a seguir mostra algumas diferenças existentes entre as duas versões do HSRP:
Importante: HSRP não possui preempt habilitado por default, ou seja, quando um router que era originalmente standby (menor priority) se torna active, ele não voltar para o estado standby caso o router com maior priority volte a ficar operacional.
Após essa introdução do funcionamento do HSRP podemos iniciar o nosso exemplo prático de utilização e para isso trabalharemos com a topologia a seguir:
O lab proposto consiste em habilitar o HSRP para que seja feita a proteção de gateway do cliente A entre os routers R10 e R20, para isso são necessárias as seguintes configurações:
R10(config)#
interface Ethernet0/0
no switchport
ip address 172.16.50.10 255.255.255.0
standby 14 ip 172.16.50.1
standby 14 priority 120
standby 14 preempt
R20(config)#
interface Ethernet0/1
no switchport
ip address 172.16.50.20 255.255.255.0
standby 14 ip 172.16.50.1
CLI_A(config)#
interface Ethernet0/0
switchport access vlan 100
switchport mode access
!
interface Ethernet0/1
switchport access vlan 100
switchport mode access
! interface Vlan100
ip address 172.16.50.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 172.16.50.1
Aplicada as configurações acima temos as seguintes definições:
- R10 será o active router do grupo HSRP 14 com priority 120 (default: 100), será utilizado o IP virtual 172.16.50.1 e com a ativação do preempt o R10 sempre que estiver operacional será o active router do grupo.
- R20 será o standby router assumindo o encaminhamento de pacotes apenas em caso de falha do R10.
- CLI_A terá uma rota default apontando para o IP virtual, em caso de falha do active router a comutação será transparente do ponto de vista do cliente.
Com o protocolo em funcionamento podemos validar algumas informações importantes que vimos na teoria conforme mostra a imagem a seguir:
Através do output do comando show standby all podemos validar o endereço IP virtual do grupo, o MAC address do grupo onde 0e representa o grupo 14 em hexadecimal, preempt ativo para que o R10 volte a ser o active router após passar por alguma falha e por fim a informação de quem é o nosso standby router.
Com a ajuda do wireshark vamos acompanhar o processo de comutação do protocolo analisando o seu comportamento:
Destacado em verde podemos ver que o R10 encaminha a sua hello message informando ser o active router do grupo. assim como o R20 encaminha informando ser o standby. Em seguida, destacado em vermelho, vemos o envio de 3 hello por parte do R20 e nenhum recebimento de hello vindo do R10, com isso o standby router entenderá que existe alguma falha ocorrendo na comunicação com o R10 e após expirar o holdtime (Por default 3 helloTime) ele assume o status de active router e envia a atualização para os demais routers conforme vemos destacado em azul.
Ao final, resolvemos o problema de redundância de gateway do cliente, porém não podemos deixar de notar que um problema ainda pode surgir. Considere a imagem a seguir:
Nesse cenário o R10 perde a sua comunicação com o restante da rede e por ainda estar com a interface para o cliente operacional, o HSRP ainda o considera como active router fazendo com que o cliente fique com o serviço down. Para resolver esse problema o HSRP possibilita a utilização de um track linkada ao valor da priority para que ocorra a comutação mesmo em caso de falha apenas da WAN do router. O exemplo a seguir demonstra a configuração e o funcionamento:
R10(config)#
track 1 interface Ethernet0/1 line-protocol
!
interface Ethernet0/0
standby 14 track 1 decrement 30
Analisando a configuração aplicada vemos que foi criada uma track que verifica o status da interface e0/1 para identificar se ela está UP ou DOWN. Caso a interface WAN e0/1 venha a ficar down, o comando standby 14 track 1 decrement 30 fará com que o R10 diminua a sua priority para 90 e dessa forma garanta a comutação do serviço para o R20 que, por ter a priority default de 100, passará a ser o active router. A imagem a seguir mostra o status do R10 após a interface e0/1 vir a DOWN:
Validamos dessa forma que mesmo tendo a priority configurada em 120, após a interface WAN ficar down o router entende, através da track configurada, que é necessário decrementar sua priority para evitar a interrupção do serviço ao cliente.
Vejamos agora o que acontece quando a interface e0/1 volta a ficar operacional:
Em azul vemos que, através da track configurada, o router verificou que a interface e0/1 voltou a ficar operacional. O HSRP ao perceber que a track indicou o status da interface como UP, retira o decremento de 30 que havia feito na priority. Em verde podemos ver a comutação do modo operacional do R10 de standby para active e isso ocorre, pois, ao retirar o decremento de 30 ele volta a ter a priority configurada de 120 que faz com que ele tenha a maior priority do grupo e por ter o preempt habilitado irá voltar a ser o active router sempre que estiver operacional no grupo.
Pois bem, agora que já temos o HSRP operando e protegendo o gateway do nosso cliente, vamos trabalhar com o seguinte cenário hipotético, apenas para fins de estudo.
Nesse cenário vamos considerar as seguintes premissas:
- R1 só consegue chegar no cliente A caso tenha uma rota estática configurada apontada ou para R10 ou para R20.
- R1 não está diretamente conectado ao R10 ou R20 e por isso não consegue detectar diretamente se um dos routers vier a down.
- Caso R10 identifique uma queda na interface WAN, ele irá forçar a comutação do tráfego para R20 através do decremento da sua priority. Contudo, R1 não tem como saber dessa queda e por isso manterá a rota estática para R10 fazendo com que o serviço do cliente seja interrompido.
Para resolver esse problema proposto, utilizaremos uma junção de IPSLA e EEM no R1 para monitorar os routers e realizar a mudança da rota estática em caso de falhas. O primeiro passo será monitorar o R10 atráves do IPSLA. Nesse caso, como sabemos que sempre que estiver acessível o R10 terá a maior priority, não precisamos monitorar o R20 pois enquanto o R10 estiver alcançável o tráfego deverá ser direcionado a ele. Segue a configuração aplicada em R1:
R1(config)#
ip sla 1
icmp-echo 10.10.10.10 source-ip 1.1.1.1
frequency 10
ip sla schedule 1 life forever start-time now
Com essa configuração definimos o IP a ser monitorado como 10.10.10.10 tendo como source o IP 1.1.1.1 correspondente a R10 e R1 respectivamente. Após isso definimos a frequência de envio dos ICMPs ECHO para 10s, respeitando o holdtime do HSRP para que ambos trabalhem em sincronia. Por fim, definimos que o IPSLA 1 irá permanecer ativo para sempre iniciando a partir do momento da configuração. Podemos validar a configuração através do comando show ip sla configuration:
Tendo o IPSLA operacional validando a conectividade entre o R1 e o R10 nos falta apenas a configuração do Event Manager. Para esse caso faremos 3 configurações:
- Criar uma track atrelada ao IPSLA para utilizarmos como evento através do seu status up/down.
- Criar um Event Manager para quando o R10 estiver down, este será responsável por excluir a rota estática direcionada ao R10 e configurar uma nova direcionada ao R20.
- Criar um Event Manager para quando o R10 estiver up, este será responsável por excluir a rota estática direcionada ao R20 e reconfigurar novamente direcionada ao R10.
Configurações aplicadas:
R1(config)#
track 1 ip sla 1 reachability
!
event manager applet R10_STATUS_DOWN
event track 1 state down
action 1.0 cli command "enable"
action 2.0 cli command "config terminal"
action 3.0 cli command "no ip route 172.16.50.0 255.255.255.0 10.10.10.10"
action 4.0 cli command "ip route 172.16.50.0 255.255.255.0 20.20.20.20"
!
event manager applet R10_STATUS_UP
event track 1 state up
action 1.0 cli command "enable"
action 2.0 cli command "config terminal"
action 3.0 cli command "no ip route 172.16.50.0 255.255.255.0 20.20.20.20"
action 4.0 cli command "ip route 172.16.50.0 255.255.255.0 10.10.10.10"
!
Com as configurações aplicadas finalmente podemos ver a solução operando como uma só simulando uma queda na interface e0/1 do R10. As imagens a seguir demonstram as mudanças ocorrendo na rede de forma detalhada.
Analisando primeiro o HSRP nos routers R10 e R20 vemos que após a interface 0/1 em R10 ficar down o protocolo percebe a falha via track 1 e rapidamente altera a priority da interface 0/0 no grupo 14 forçando o router a se tornar o standby. Em seguida vemos o log em R20 mostrando que ele se tornou o active router do grupo.
Do ponto de vista do R1 após o IPSLA verificar a falta de conectividade com o R10 a track 1 passa para o status down fazendo com que o Event Manage realize as actions configuradas alterando a rota estática para chegar no cliente A através do R20
Apesar de aparentemente a solução ter funcioando como o esperado, vocês devem ter percebido que ainda temos um ponto de falha. O que ocorre quando apenas a interface e0/0 do R10 ficar down?
Caso ocorra uma queda na interface e0/0 do R10, o HSRP entenderá a falha e realizará a comutação do R20 de standby para active router. Contudo, do ponto de vista do R1 não tem como ele saber dessa queda pois só monitora a conexão via interface via e0/0 através do IP 10.10.10.10. Para resolver isso iremos criar o seguinte Event Manager no router R10:
R10(config)#
event manager applet e0/0_DOWN
event syslog pattern "Interface Ethernet0/0.* down" period 1
action 1.0 cli command "enable"
action 2.0 cli command "configure terminal"
action 3.0 cli command "interface Loopback0"
action 4.0 cli command "no ip ospf 1 area 0"
!
event manager applet e0/0_UP
event syslog pattern "Interface Ethernet0/0.* up" period 1
action 1.0 cli command "enable"
action 2.0 cli command "configure terminal"
action 3.0 cli command "interface Loopback0"
action 4.0 cli command "ip ospf 1 area 0"
Com a criação desses dois event manager sempre que o R10 verificar que a interface e0/0 ficou down ele irá retirar a interface loopback0 de dentro do OSPF. Com o R1 realiza o monitoramento através do IP configurado nessa loopback ele também conseguirá identificar a falha e realizar a comutação do tráfego. As imagens a seguir demostram o funcionamento em caso de falhas da interface e0/0 do R10:
R10 identifica a falha na e0/0 e realiza a comutação do estado HSRP de Active para Init. Com o EMM configurado o R10 também realiza a remoção da loopback0 do processo OSPF forçando assim a comutação em R1 conforme imagem a seguir:
Ao final temos uma solução que atende ao requisito do negócio de forma simples para garantir a melhora na disponibilidade do serviço ao cliente.
Temos em mente que essa não é a única e nem a melhor solução para o problema, a ideia desse artigo é trazer um cenário em que podemos aplicar alguns protocolos comumente abordados nas certificações! Espero que isso consiga clarear algumas formas de aplicação e ajudar nos estudos de quem está em busca de certificações.
Até a próxima!
