O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como o Hot Standby Router Protocol (HSRP) funciona e analisa seus recursos.
Não existem requisitos específicos para este documento.
Este documento não se restringe a versões de software e hardware específicas.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.
Uma maneira de obter quase 100% de tempo de atividade da rede é usar o HSRP, que fornece redundância de rede para redes IP e garante que o tráfego do usuário se recupere imediatamente e de forma transparente das primeiras falhas de salto nos dispositivos de borda da rede ou nos circuitos de acesso.
Quando dois ou mais roteadores compartilham um endereço IP e um endereço MAC (Camada 2), eles podem atuar como um único roteador "virtual". Os membros do grupo de roteadores virtuais transferem continuamente mensagens de status. Dessa forma, um roteador pode assumir a responsabilidade de roteamento de outro se um estiver fora de serviço por motivos planejados ou não planejados. Os hosts continuam a encaminhar pacotes IP para um endereço IP e MAC consistente, e a mudança de dispositivos que fazem o roteamento é transparente.
Isso fornece descrições de mecanismos de descoberta dinâmica de roteador que estão disponíveis para os hosts. Muitos desses mecanismos não fornecem a resiliência de rede exigida pelos administradores de rede. Isso pode ser causado quando o protocolo não foi inicialmente projetado para fornecer resiliência de rede ou porque não é viável para cada host em uma rede executar o protocolo. Além do que está listado, é importante observar que muitos hosts permitem apenas que você configure um gateway padrão.
Alguns hosts IP usam o ARP (Address Resolution Protocol) para selecionar um roteador. Quando um host executa proxy ARP, envia uma solicitação de ARP para o endereço IP do host remoto que desejar contatar. Um roteador da rede, o Roteador A, responde em nome do host remoto e fornece seu próprio endereço MAC. Com o ARP proxy, o host se comporta como se o host remoto estivesse conectado ao mesmo segmento da rede. Se o Roteador A falhar, o host continuará a enviar pacotes destinados ao host remota para o endereço MAC do Roteador A, mesmo que esses pacotes não tenham para onde ir e sejam perdidos. Você pode esperar que o ARP adquira o endereço MAC de outro roteador, o Roteador B, no segmento local que envia outra solicitação ARP ou reinicializar o host para forçá-lo a enviar uma solicitação ARP. Em ambos os casos, por um período de tempo significativo, o host não pode se comunicar com o host remoto, mesmo que o protocolo de roteamento tenha convergido e o Roteador B esteja preparado para transferir pacotes que, de outra forma, passariam pelo Roteador A.
Alguns hosts IP executam (ou rastreiam) um protocolo de roteamento dinâmico, como o Routing Information Protocol (RIP) ou o Open Shortest Path First (OSPF), para descobrir roteadores. A desvantagem de usar o RIP é que ele é lento para se adaptar às alterações na topologia. Para executar um protocolo de roteamento dinâmico em cada host, isso não é prático por vários motivos, juntamente com a sobrecarga administrativa, processing
sobrecarga, problemas de segurança ou falta de uma implementação de protocolo para algumas considerações de plataformas.
Alguns hosts IP mais recentes usam o IRDP (ICMP Router Discovery Protocol) (RFC 1256 ) para encontrar um novo roteador quando uma rota se torna indisponível. Um host que executa IRDP ouve mensagens multicast de Hello do roteador configurado e usa um roteador alternativo quando ele não recebe mais essas mensagens Hello. Os valores de temporizador padrão do IRDP significam que ele não é adequado para a detecção de falha do primeiro salto. A taxa de anúncio padrão é um a cada 7 a 10 minutos, e o tempo de vida padrão é de 30 minutos.
O Dynamic Host Configuration Protocol (DHCP) ( RFC 1531) fornece um mecanismo para passar as informações de configuração aos hosts em uma rede TCP/IP. Um host que executa um cliente DHCP solicita informações de configuração de um servidor DHCP quando é inicializado na rede. Essas informações de configuração geralmente abrangem um endereço IP e um gateway padrão. Não há mecanismo para alternar para um roteador alternativo se o gateway padrão falhar.
Uma grande classe de implementações de hosts legados que não suporta a descoberta dinâmica pode configurar um roteador padrão. Executar um mecanismo dinâmico de descoberta de roteador em cada host não é prático por vários motivos, juntamente com a sobrecarga administrativa, processing
sobrecarga, problemas de segurança ou falta de uma implementação de protocolo para algumas considerações de plataformas. O HSRP fornece serviços de failover para esses hosts.
Quando você usa o HSRP, um conjunto de roteadores funciona em conjunto para apresentar a ilusão de um único roteador virtual para os hosts na LAN. Esse conjunto é conhecido como grupo de HSRP ou grupo em espera. Um único roteador eleito do grupo é responsável pela distribuição dos pacotes que os hosts enviam ao roteador virtual. Esse roteador é conhecido como o roteador ativo. Outro roteador está eleito como roteador em standby. Em caso de falha do roteador ativo, o standby assume o comando packet-forwarding
funções do roteador ativo. Embora um número arbitrário de roteadores possa executar o HSRP, somente o roteador Ativo encaminha os pacotes enviados ao roteador virtual.
Para minimizar o tráfego da rede, somente os roteadores Ativo e Em Espera enviam mensagens de HSRP periódicas após o protocolo ter concluído o processo de eleição. Se o roteador ativo falhar, o roteador em standby assume como o roteador ativo. Se o roteador em standby falhar ou se tornar um roteador ativo, então outro roteador é escolhido como roteador em standby.
Em uma LAN específica, vários grupos em espera ativa podem coexistir e se sobrepor. Cada grupo em standby emula um único roteador virtual. Os roteadores individuais podem participar de vários grupos. Nesse caso, o roteador mantém estado e cronômetros separados para cada grupo. Cada grupo em standby tem um único endereço MAC e um único endereço IP conhecidos.
Na maioria dos casos, quando você configura roteadores para fazerem parte de um grupo HSRP, eles ouvem o endereço MAC do HSRP desse grupo e também os seus próprios endereços de operação. A exceção são os roteadores cujos controladores Ethernet reconhecem apenas um único endereço MAC (por exemplo, o controlador Lance nos roteadores Cisco 2500 e Cisco 4500). Esses roteadores usam o endereço MAC do HSRP quando são o roteador ativo e seu endereço gravado quando não são.
O HSRP usa esse endereço MAC em todas as mídias, exceto Token Ring:
0000.0c07.ac** (where ** is the HSRP group number)
Este documento mostra quais recursos HSRP são suportados em quais versões do Cisco IOS Software. Clique no recurso para visualizar uma descrição detalhada. Um número de versão temporária indica em que versão um recurso apareceu primeiro ou uma versão em que a funcionalidade desse recurso foi alterada.
Recurso |
12.0 |
12.0T |
12.1 |
12.1T |
X |
X |
X |
X |
|
X |
X |
X |
X |
|
X |
X |
X |
X |
|
X |
X |
X |
X |
|
X |
X |
X |
X |
|
6.1 |
X |
X |
X |
|
X |
X |
X |
X |
|
X |
X |
X |
X |
|
X |
X |
X |
X |
|
X |
X |
X |
X |
|
1.0 |
X |
X |
X |
|
— |
3.0 |
X |
X |
|
— |
3.4 |
X |
X |
|
— |
3.4 |
X |
X |
|
— |
6.2 |
X |
X |
|
— |
8.1 |
X |
X |
|
— |
— |
0,2 |
X |
|
— |
— |
— |
3 |
|
— |
— |
— |
3 |
O recurso de antecipação do HSRP permite que o roteador com a prioridade mais alta se torne imediatamente o roteador ativo. A prioridade é determinada, primeiro, pelo valor de prioridade que você configura e, então, pelo endereço IP. Em cada caso, o valor mais alto tem maior prioridade. Quando um roteador de prioridade mais alta apropriar-se de um roteador de prioridade mais baixa, ele enviará uma mensagem de processo. Quando um roteador ativo de prioridade mais baixa recebe uma mensagem coup ou hello de um roteador ativo de prioridade mais alta, ele passa para o estado de fala e envia uma mensagem resign.
O recurso de retardo de apropriação permite que a apropriação seja atrasada por um período de tempo configurável e permite que o roteador preencha sua tabela de roteamento antes de se tornar o roteador ativo.
Antes do software Cisco IOS versão 12.0(9), o atraso iniciava quando o roteador era recarregado. No Cisco IOS versão 12.0(9), o retardo começa quando a antecipação é a primeira tentativa.
Para configurar a prioridade e a apropriação do HSRP, use o comando standby <group> <priority number> <preempt [delay [minimum]seconds] [syncseconds]> . Consulte a Documentação do HSRP para obter mais informações.
Tracking
Interface tracking
permite especificar outra interface no roteador para que o processo HSRP seja monitorado a fim de alterar a prioridade HSRP para um determinado grupo.
Se o protocolo de linha especificado da interface ficar inativo, a prioridade de HSRP desse roteador será reduzida e permitirá que outro roteador de HSRP com prioridade mais alta se torne ativo (se tiver a preempção habilitada).
Para configurar a interface do HSRP tracking
use o comando standby <group> track interface <priority>.
Observação: a disponibilidade do comando Interface Track pode depender da versão do software usado, mas o comando standby <group> track <object> pode ser usado.
Quando várias interfaces controladas estão desativadas, a prioridade é reduzida em uma quantidade cumulativa. Se você definir explicitamente o valor de decréscimo, esse valor será reduzido com base nessa quantidade se a interface for desativada e os decréscimos são cumulativos. Se você não definir uma diminuição explícita de valor, o valor será diminuído em 10 para cada interface desativada, e as diminuições serão acumulativas.
Este exemplo usa esta configuração, com o valor de decréscimo padrão de 10:
Observação: quando um número de grupo do HSRP não é especificado, o número de grupo padrão é o grupo 0.
interface ethernet0 ip address 10.1.1.1 255.255.255.0 standby ip 10.1.1.3 standby priority 110 standby track serial0 standby track serial1
O comportamento HSRP com essa configuração é:
0 interfaces inativas = nenhuma diminuição (a prioridade é 110)
1 interface inativa = redução de 10 (a prioridade passa a ser 100)
2 interfaces inativas = diminuir em 10 (a prioridade torna-se 90)
O comportamento de HSRP mencionado anteriormente é verdadeiro mesmo se os valores de decréscimo forem configurados explicitamente como:
interface ethernet0 ip address 10.1.1.1 255.255.255.0 standby ip 10.1.1.3 standby priority 110 standby track serial0 10 standby track serial1 10
Antes do Cisco IOS versão 12.1, se você iniciar um roteador com uma interface inativa, a interface HSRP tracking
considera a interface como ativa.
O recurso de uso de endereço gravado (BIA) permite que grupos HSRP usem um endereço MAC gravado da interface em vez de um endereço MAC HSRP. O uso do BIA foi implementado pela primeira vez no Cisco IOS versão 11.1(8). Para configurar o HSRP para usar o BIA, use o comando standby use-bia <scope interface>.
O comando use-bia foi implementado para superar as limitações quando um endereço funcional para o endereço MAC HSRP nas interfaces Token Ring é usado.
Observação: quando o HSRP é executado em um ambiente de Source-Routed Bridging de vários anéis e os roteadores HSRP residem em anéis diferentes e usam os endereços funcionais, isso pode causar confusão no Routing Information Field (RIF). Por esta razão, o comando use-bia foi introduzido.
O recurso use-biatambém permite o uso de DECnet, Xerox Network Systems (XNS) e HSRP no mesmo roteador pelo uso do endereço MAC DECnet (o BIA) a ser usado como o endereço MAC HSRP. O comando use-bia também é útil para redes onde o BIA do dispositivo foi configurado em outros dispositivos na LAN.
No entanto, o comando use-bia tem diversas desvantagens:
Quando um roteador fica ativo, o endereço IP virtual é movido para um endereço MAC diferente. O roteador recém-ativado envia uma resposta de ARP gratuita, mas nem todas as implementações de host tratam o ARP gratuito corretamente.
O ARP do proxy é interrompido quando o comando use-bia é configurado. Um roteador em standby não pode cobrir o banco de dados ARP de proxy perdido de um roteador com falha.
Antes da versão 12.0(3.4)T do Cisco IOS, apenas um grupo de HSRP era permitido se o use-bia estivesse configurado.
Quando você configura o comando use-bia em uma subinterface, ele na verdade aparece na interface principal e é aplicado a todas as subinterfaces. No Cisco IOS versão 12.0(6.2) e posterior, o comando use-bia é estendido com as palavras-chave da interface de escopo opcional para permitir que seja aplicado a uma única subinterface.
O recurso de MHSRP (Vários grupos de HSRP) foi incluído no Cisco IOS versão 10.3. Esse recurso permite ainda mais redundância e compartilhamento de carga nas redes e permite que roteadores redundantes sejam utilizados mais plenamente. Enquanto um roteador encaminha ativamente o tráfego para um grupo de HSRP, ele pode estar em espera ou no estado de escuta para outro grupo.
A partir do Cisco IOS versão 12.0(3.4)T, você pode usar o comando use-bia com vários grupos de HSRP ativados. Consulte Compartilhamento de Carga com HSRP para configurar o HSRP e aproveitar os vários caminhos.
Normalmente, você usa o HSRP para ajudar as estações finais a localizar o primeiro gateway de salto para o roteamento IP. As estações finais são configuradas com um gateway padrão. Entretanto, o HSRP pode fornecer a primeira redundância de nó para outros protocolos. Alguns protocolos, como o APPN (Rede peer-to-peer avançada), usam o MAC Address para identificar o primeiro salto para o roteamento.
Nesse caso, muitas vezes é necessário poder especificar o endereço MAC virtual que usa o comando standby mac-address. O endereço IP virtual não é importante para esses protocolos. A sintaxe real do comando é standby [group] mac-address mac-address.
Observação: você não pode usar esse comando em uma interface de token ring.
Suporte para syslog messaging
para obter informações de HSRP foi adicionado no Cisco IOS versão 11.3. Esse recurso permite uma utilização mais logging
e tracking
dos roteadores ativos e em standby atuais nos servidores syslog.
Antes do Cisco IOS versão 12.1, o comando de depuração do HSRP era relativamente simples. Para ativar a depuração HSRP, deve-se simplesmente usar o comando debug standby, que habilita a saída do estado de HSRP e as informações do pacote de todos os grupos em standby em todas as interfaces.
Uma condição de depuração foi adicionada ao Cisco IOS versão 12.0(2.1) permitindo que a saída o comando standby debug seja filtrada com base na interface e no número do grupo. O comando utiliza o paradigma debug condition introduzido no Cisco IOS versão 12.0, como a seguir: debug condition standby interface group . A interface especificada deve ser uma interface válida que possa suportar HSRP. O grupo pode ser qualquer grupo (0-255).
Você pode definir condições de depuração para grupos que não existem, o que permite capturar informações de depuração durante a inicialização de um novo grupo.
O standby debug order deve estar habilitado para qualquer tipo de saída de depuração a ser produzida. Se você não configurar nenhuma condição de depuração em espera, a saída da depuração será produzida para todos os grupos em todas as interfaces. Se você configurar pelo menos uma condição de depuração em standby, a saída da depuração em standby será filtrada por todas as condições de depuração em standby.
Antes do Cisco IOS versão 12.1(0.2), a depuração de HSRP era de uso limitado porque as informações eram perdidas no ruído das mensagens de Hello periódicas. Assim, o recurso de depuração avançada foi adicionado ao Cisco IOS 12.1(0.2).
A tabela explica as opções de comando para a depuração avançada.
Comando |
Descrição |
---|---|
Exibe todos os erros, eventos e pacotes HSRP. |
|
Exibe todos os erros, eventos e pacotes de HSRP, exceto os pacotes hello e de anúncio. |
|
Exibe erros HSRP. |
|
debug standby events <[all | terse] | [icmp | protocol | redundância | track]> [detail] |
Exibe eventos de HSRP. |
debug standby packets <[all | terse] | [advertise | coup | olá | resign]> [detail] |
Exibe pacotes HSRP. |
Você pode filtrar a saída de debug com a interface e a depuração condicional do grupo HSRP. Para ativar a depuração condicional de interface, use o comando debug condition interface interface. Para ativar a depuração condicional de HSRP, use o comando debug condition standby interface group.
Uma condição de depuração de interface se aplica apenas quando não são definidas condições de depuração em espera. A depuração HSRP é ainda mais aprimorada no software Cisco IOS versão 12.1(1.3), com base nas melhorias que foram feitas na tabela de estado do HSRP.
Estas melhorias apresentam os eventos da tabela de estados de HSRP. Na saída, a a/ , b/ , c/ e assim por diante, referem-se aos eventos da máquina de estado finito HSRP, que estão documentados na RFC 2281.
SB1: Ethernet0/2 Init: a/HSRP enabled SB1: Ethernet0/2 Active: b/HSRP disabled (interface down) SB1: Ethernet0/2 Listen: c/Active timer expired (unknown) SB1: Ethernet0/2 Active: d/Standby timer expired (10.0.0.3) SB1: Ethernet0/2 Speak: f/Hello rcvd from higher pri Speak router SB1: Ethernet0/2 Active: g/Hello rcvd from higher pri Active router SB1: Ethernet0/2 Speak: h/Hello rcvd from lower pri Active router SB1: Ethernet0/2 Standby: i/Resign rcvd SB1: Ethernet0/2 Active: j/Coup rcvd from higher pri router SB1: Ethernet0/2 Standby: k/Hello rcvd from higher pri Standby router SB1: Ethernet0/2 Standby: l/Hello rcvd from lower pri Standby router SB1: Ethernet0/2 Active: m/Standby mac address changed SB1: Ethernet0/2 Active: n/Standby IP address configured
O recurso de autenticação HSRP consiste em uma chave de texto claro compartilhada com os pacotes HSRP. Esse recurso impede que o roteador de prioridade mais baixa learning
os valores do endereço IP em standby e do temporizador em standby do roteador de prioridade mais alta.
Para configurar a string de autenticação do HSRP, use o comando standby authentication <string>.
O HSRP fornece redundância stateless para roteamento IP. O HSRP pode manter apenas seu próprio estado. Ele pressupõe que cada roteador cria e mantém as próprias tabelas de roteamento independentemente de outros roteadores. O recurso de redundância de IP fornece um mecanismo que permite que o HSRP forneça um serviço a aplicativos cliente para que eles possam implementar failover stateful.
A redundância de IP não fornece um mecanismo de aplicações de peer para trocar informações de estado. Isso é deixado para os próprios aplicativos e é essencial para que os aplicativos forneçam failover stateful.
A redundância de IP geralmente é implementada apenas para Agentes Móveis IP Domésticos. Esta é uma configuração de exemplo:
configure terminal router mobile ip mobile home-agent standby hsrp-group1 ! interface e0/2 no shutdown ip address 10.0.0.1 255.0.0.0 standby 1 ip 10.0.0.11 standby 1 name hsrp-group1
Observação: a partir do Cisco IOS versão 12.1(3)T, a redundância de palavra-chave é aceita, além da palavra-chave standby. A palavra-chave standby é desativada em uma versão posterior do Cisco IOS. O comando correto é ip mobile home-agent redundancy hsrp-group1 .
Os usos futuros da redundância de IP incluem:
NAT - Precisa fornecer gateways redundantes.
IPSEC - É preciso sincronizar as informações de estado para operação quando o HSRP está em uso.
Servidor DHCP - Servidores DHCP implementados em vários roteadores.
NBAR, CBAC - Precisa refletir estados de firewall para roteamento assimétrico.
GPRS – Necessita encontrar uma maneira de rastrear o estado de TCP.
O suporte à base de informações de gerenciamento (MIB) do SNMP foi adicionado ao Cisco IOS versão 12.0(3.0)T. Há dois MIBs relevantes para HSRP:
ciscoMgmt 106: O módulo MIB usado para gerenciar o HSRP
ciscoMgmt 107: O módulo MIB de extensão usado para gerenciar o HSRP
Antes do Cisco IOS versão 12.0(6.1)T, uma passagem da MIB estendida para HSRP quando uma Bridge Group Virtual Interface (BVI) está presente causa um defeito no roteador.
O suporte HSRP para Virtual Private Networks de switching de rótulo multiprotocolo (MPLS VPNs) foi adicionado ao Cisco IOS versão 12.1(3)T.
O HSRP em uma interface VPN MPLS é útil quando você tem uma Ethernet conectada entre duas Bordas do Provedor (PEs) e tem uma destas:
R Customer
Edge (CE) com uma rota padrão para o endereço IP virtual do HSRP.
Um ou mais hosts com o endereço IP virtual do HSRP configurado como gateway padrão.
O diagrama de rede mostra dois PEs com HSRP que são executados entre suas VPNs routing/forwarding
(VRF). O CE com o endereço IP virtual do HSRP é configurado como sua rota padrão. E o HSRP é configurado para rastrear as interfaces que conectam os PEs ao restante da rede do provedor. Por exemplo, se a interface E1 do PE1 falhar, a prioridade do HSRP será reduzida de modo que o PE2 assuma o controle forwarding
pacotes para o endereço IP/MAC virtual.
Estas são as configurações:
Roteador PE1 | Roteador PE2 |
---|---|
ip cef ! ip vrf vrf1 rd 100:1 route-target export 100:1 route-target import 100:1 ! interface ethernet0 no shutdown ip vrf forwarding vrf1 ip address 10.2.0.1 255.255.0.0 standby 1 ip 10.2.0.20 standby 1 priority 105 standby 1 preempt delay minimum 10 standby 1 timers 3 10 standby 1 track ethernet1 10 standby 1 track ethernet2 10 |
ip cef ! ip vrf vrf1 rd 100:1 route-target export 100:1 route-target import 100:1 ! interface ethernet0 no shutdown ip vrf forwarding vrf1 ip address 10.2.0.2 255.255.0.0 standby 1 ip 10.2.0.20 standby 1 priority 100 standby 1 preempt delay minimum 10 standby 1 timers 3 10 standby 1 track ethernet1 10 standby 1 track ethernet2 10 |
Você pode usar os próximos comandos para verificar se o endereço IP virtual do HSRP está no ARP VRF correto e no Cisco Express Forwarding
tabelas:
ed1-pe1#show ip arp vrf vrf1 Protocol Address Age (min) Hardware Addr Type Interface Internet 10.2.0.1 - 00d0.bbd3.bc22 ARPA Ethernet0/2 Internet 10.2.0.20 - 0000.0c07.ac01 ARPA Ethernet0/2 ed1-pe1#show ip cef vrf vrf1 Prefix Next Hop Interface 0.0.0.0/0 10.3.0.4 Ethernet0/3 0.0.0.0/32 receive 10.1.0.0/16 10.2.0.1 Ethernet0/2 10.2.0.0/16 attached Ethernet0/2 10.2.0.1/32 receive 10.2.0.20/32 receive 224.0.0.0/24 receive 255.255.255.255/32 receive
O HSRP se baseia no conceito de que os roteadores pares do HSRP que protegem uma sub-rede podem fornecer acesso a todas as outras sub-redes que compõem a rede. Portanto, é irrelevante saber qual roteador se tornou o roteador HSRP ativo, pois todos os roteadores possuíam rotas para cada sub-rede.
O HSRP utiliza um endereço IP virtual especial e um endereço MAC virtual, que estão logicamente conectados ao roteador ativo do HSRP. Os redirecionamentos de ICMP são desativados automaticamente em uma interface quando o HSRP é usado nessa interface. A partir do Cisco IOS 12.1(3)T, o recurso Redirecionamentos ICMP habilita os redirecionamentos ICMP nas interfaces configuradas com HSRP. Consulte o suporte de HSRP para redirecionamentos de ICMP para obter mais detalhes. Isso é feito para evitar que os hosts sejam redirecionados para longe do endereço IP virtual do HSRP. É possível que os dois (ou mais) roteadores em uma sub-rede não tenham conectividade idêntica com o restante da rede. Ou seja, para um endereço IP de destino específico, um ou outro dos roteadores pode ter um caminho muito melhor para esse endereço ou pode até mesmo ser o único roteador conectado a esse endereço.
O protocolo ICMP permite que um roteador redirecione uma estação final para enviar pacotes de um determinado destino para outro roteador na mesma sub-rede. Isto se o primeiro roteador souber que o outro roteador tem um caminho melhor para aquele destino em particular. Como foi o caso dos gateways padrão, se o roteador para o qual uma estação final foi redirecionada para um destino específico falhar, os pacotes da estação final para esse destino não foram entregues. Em HSRP padrão, é exatamente isto o que acontece. Por esse motivo, é recomendável desabilitar os redirecionamentos de ICMP se o HSRP estiver ativado.
Quando você estende o relacionamento entre os redirecionamentos de ICMP e o HSRP, é fornecida uma solução para esse problema, permitindo que você aproveite os benefícios dos redirecionamentos de HSRP e ICMP. Dois (ou mais) grupos de HSRP são executados em cada sub-rede, com pelo menos tantos grupos de HSRP configurados quantos os roteadores que participam. As prioridades são configuradas de modo que cada roteador seja o roteador principal de pelo menos um grupo HSRP. Quando um roteador determina redirecionar uma estação final para um roteador diferente para um destino específico, em vez de redirecionar para a estação final para esse outro endereço IP do roteador, ele encontra um grupo de HSRP que tem esse roteador como seu roteador primário e redireciona a estação final para o endereço IP virtual correspondente. Se o roteador de destino falhar, o HSRP garantirá que outro roteador assuma o trabalho e talvez redirecione a estação final para outro roteador virtual.
O suporte de HSRP a BVIs (Bridge Group Virtual Interfaces, Grupos virtuais de interface de ponte) foi adicionado no Cisco IOS versão 12.0(6.2)T.
Os grupos de HSRP em subinterfaces devem ter um número de grupo exclusivo entre todos os outros grupos em todas as subinterfaces na mesma interface principal. Isso ocorre porque as subinterfaces não recebem um índice de interface SNMP exclusivo. Se você tivesse dois grupos com o número N em diferentes subinterfaces, então, no MIB, o grupo N na subinterface 1 e o grupo N na subinterface 2 pareceriam ser o mesmo grupo.
Revisão | Data de publicação | Comentários |
---|---|---|
4.0 |
13-Sep-2023 |
Recertificação |
3.0 |
05-Aug-2022 |
Versão inicial |
1.0 |
02-Dec-2013 |
Versão inicial |