Redundância de first hop: VRRP, HSRP e o gateway que é uma ficção

Os protocolos de redundância de first hop, como o VRRP e o HSRP, fazem vários roteadores dividirem um único endereço de default gateway e um único MAC virtual, para que os hosts continuem encaminhando tráfego quando o roteador por trás desse endereço cai. Depois da leitura, você consegue dizer o que um host faz e o que não faz sozinho, calcular o tempo de failover do VRRPv3 a partir da prioridade e do intervalo, comparar os defaults do HSRP, reconhecer as falhas comuns e a superfície de ataque e encontrar os dois protocolos numa captura e na saída dos roteadores.

Ver em Markdown

Um host IPv4 manda tudo o que sai da sub-rede a um único endereço, o default gateway, e o roteador por trás dele vira ponto único de falha. A redundância de first hop resolve isso pelo lado da rede. O Virtual Router Redundancy Protocol (VRRP), padrão da Internet Engineering Task Force (), e o Hot Standby Router Protocol (HSRP), mais antigo e da Cisco, fazem vários roteadores dividirem o IP do gateway e um endereço media access control (MAC), um respondendo de cada vez. Depois da leitura, você consegue dizer o que o host faz sozinho, calcular um failover do VRRP, comparar com o HSRP e reconhecer e capturar os dois.

O que o host consegue fazer sozinho

Mais do que se costuma dizer. A (RFC) 1122, de 1989, diz que "The IP layer MUST support multiple default gateways", suporte obrigatório a vários default gateways (RFC 1122, seção 3.3.1.2), e que "The IP layer MUST be able to detect the failure of a 'next-hop' gateway that is listed in its route cache and to choose an alternate gateway", detectar a falha do gateway e escolher outro (seção 3.3.1.4), trocando de default quando conhece mais de um (seção 3.3.1.5). E admite que "Experience to date has not produced a complete algorithm which is totally satisfactory", falta um algoritmo satisfatório (seção 3.3.1.4).

A detecção fica com cada implementação, e um host com um único gateway, configurado à mão ou pelo Dynamic Host Configuration Protocol (), não tem para onde ir. O Router Discovery do Internet Control Message Protocol () anuncia a cada 7 a 10 minutos por padrão, pouco para detectar um first hop morto, diz a própria RFC (RFC 1256, seção 2). A RFC 9568, o padrão atual do VRRP, tira a conclusão: "Loss of the default router results in a catastrophic event, isolating all end-hosts that are unable to detect an available alternate path", o host sem caminho alternativo fica isolado (RFC 9568, seção 1.3). A redundância de first hop resolve sem mexer em host nenhum.

O roteador virtual

Numa local area network (), a RFC 9568 define o Virtual Router como "An abstract object managed by VRRP that acts as a default router for hosts on a shared LAN", um objeto abstrato que serve de default router (RFC 9568, seção 1.7). Ele tem um Virtual Router Identifier (VRID) de 1 a 255 e um conjunto de endereços; o Active Router encaminha, os Backup Routers esperam. Quem tem o endereço virtual como endereço real de interface é o address owner, sempre ativo quando disponível (seção 1.7). O HSRP proíbe isso: o endereço do grupo tem de diferir de todo endereço real da LAN (RFC 2281, seção 1).

A RFC 9568 (abril de 2024) substitui a RFC 5798 (março de 2010), que substituiu a RFC 3768 (abril de 2004) (RFC 9568, Abstract), sucessora da RFC 2338 (abril de 1998) (RFC 3768, seção 13). Ela também renomeou o roteador que encaminha: "The term for the VRRP Router assuming forwarding responsibility has been changed to 'Active Router' to be consistent with IETF inclusive terminology", troca feita por linguagem inclusiva (seção 1.1). As RFCs antigas e as implementações atuais dizem Master.

A RFC 2281 (março de 1998), do HSRP, é Informational e não define padrão nenhum (RFC 2281, Status of this Memo). Sua seção 2 citava a patente americana 5.473.599, de 5 de dezembro de 1995, mas a errata verificada 464 diz que ela "was mistakenly included in the document and is incorrect", entrou por engano (errata da RFC 2281).

Os dois endereços mudam de lugar, e o MAC é o que importa

Protocolo	MAC virtual	Onde está definido
VRRP para IPv4	`00-00-5E-00-01-{VRID}`	RFC 9568, seção 7.3
VRRP para IPv6	`00-00-5E-00-02-{VRID}`	RFC 9568, seção 7.3
HSRP versão 1	`00-00-0C-07-AC-XX`, XX é o número do grupo	RFC 2281, seção 6.1
HSRP versão 2	`0000.0C9F.F000` a `0000.0C9F.FFFF`	Cisco, Configuring HSRP

00-00-5E é o Organizationally Unique Identifier (OUI) da Internet Assigned Numbers Authority (), e a RFC 9542 dá os blocos 00-01 e 00-02 dele ao VRRP para IPv4 e IPv6 (RFC 9542, seções 1.3 e 2.1.3; IANA, IANA OUI Ethernet Numbers). O último octeto é o VRID ou o grupo em hexadecimal: o VRID 5 dá 00-00-5E-00-01-05, e o grupo 10 do HSRP dá 00-00-0C-07-AC-0A.

Os hosts resolvem o gateway pelo Address Resolution Protocol (), e a resposta é o MAC virtual: "The Active Router MUST NOT respond with its physical in the ARP response. This allows the host to always use the same MAC address, regardless of the current Active Router", o host usa sempre o mesmo MAC, seja quem for o ativo (RFC 9568, seção 8.1.2). Depois do failover, nada mudou no cache do host.

O que muda é a porta do switch atrás do MAC. O Active Router usa o MAC virtual como origem dos advertisements, porque, sem isso, "the MAC address location is never learned, resulting in flooding of all packets sent to the Virtual Router", o switch inunda tudo o que vai para o roteador virtual (seção 2.4). Ao assumir, ele manda um para cada IPv4 virtual ou, no IPv6, um Neighbor Advertisement não solicitado com a flag Override (seção 6.4.2, com a correção da errata verificada 7949). Os vizinhos atualizam a entrada pela regra de merge do ARP e os switches reaprendem a porta. No HSRP, o anúncio é uma resposta ARP (RFC 2281, seção 5.6).

VRRPv3: o advertisement e a eleição

O VRRP versão 3 tem uma só mensagem, o ADVERTISEMENT, enviada pelo Active Router com o VRID, a prioridade, um intervalo de 12 bits em centissegundos e os endereços virtuais (RFC 9568, seções 5.1 e 5.2). As regras que decidem quem fica ativo:

Regra	Valor	Onde está na RFC 9568
Prioridade do owner	255	seção 5.2.4
Prioridade de um Backup	1 a 254, default 100	seção 5.2.4
Prioridade 0	o Active Router sai; os Backups assumem depois do Skew_Time	seção 5.2.4
Empate	vence o maior endereço primário, comparado como inteiro sem sinal	seção 6.4.3
Preempt_Mode	default True; o owner sempre faz preemption	seção 6.1
Accept_Mode	default False: quem não é owner não aceita pacotes para o endereço virtual, então um ping para ele pode falhar	seção 6.1

Os timers, calculados

O intervalo tem default de 100 centissegundos, um segundo (RFC 9568, seção 5.2.7), configurável de 1 a 4095 pela errata verificada 8301. Um Backup declara o Active Router morto pelas fórmulas da seção 6.1:

Skew_Time            = ((256 - Priority) * Active_Adver_Interval) / 256
Active_Down_Interval = (3 * Active_Adver_Interval) + Skew_Time

Nos defaults, (256 - 100) x 100 / 256 dá 15.600 dividido por 256, um skew de 60,9375 centissegundos, e o Backup espera 360,9375 centissegundos, 3,6094 segundos:

Prioridade do Backup	Skew_Time	Active_Down_Interval
254	0,7812 cs	300,7812 cs (3,0078 s)
200	21,8750 cs	321,8750 cs (3,2188 s)
100 (default)	60,9375 cs	360,9375 cs (3,6094 s)
1	99,6094 cs	399,6094 cs (3,9961 s)

O skew faz o melhor Backup agir primeiro, e "faster convergence can be obtained by using a higher priority for the preferred Backup Router", prioridade maior para o Backup preferido (RFC 9568, seção 8.3.2). A seção 3 promete menos de 4 segundos no default e menos de 1/25 de segundo se configurado; o Backup mais lento da tabela espera 3,9961 segundos, e com intervalo de 1 centissegundo a prioridade 254 espera 3,0078 centissegundos, uns 30 milissegundos. A RFC não define arredondamento; o FRRouting (FRR) usa centissegundos inteiros e mostra 210 ms de skew na prioridade 200, contra os 21,875 centissegundos exatos (documentação do FRRouting, VRRP). O Python playground refaz a conta.

HSRP: a mesma ideia, outros números

	VRRPv3	HSRP versão 1
Transporte	protocolo IP 112 para 224.0.0.18 ou ff02::12, Time to Live () 255	UDP 1985 para 224.0.0.2, TTL 1
Timers	advertisement a cada 1 s, Active dado como morto em 3,6094 s na prioridade 100	hello de 3 s, hold time de 10 s
Estados	Initialize, Backup, Active	Initial, Learn, Listen, Speak, Standby, Active
Preemption	ligada por default	só se configurada
ICMP redirects	podem ser usados	MUST NOT, proibidos
Status	Proposed Standard	Informational

A coluna do HSRP vem da RFC 2281 (RFC 2281, seções 5.1, 5.3 e 6.3), a do VRRP da RFC 9568, seções 5.1, 6.3 e 8.1.1. Como no VRRP, o maior endereço desempata (RFC 2281, seção 5.1). A Cisco usa os mesmos defaults: "The default hello interval is 3 seconds. The default hold time is 10 seconds", 3 e 10 segundos (Cisco, command reference). O standby age 10 segundos após o último hello, 2,77 vezes os 3,61 segundos do VRRPv3. Sem o comando standby preempt, diz a Cisco, um roteador "will not become the active router, even if its priority is higher than all other routers", nem com a maior prioridade (Cisco, Configuring HSRP). A versão 2 traz grupos de 0 a 4095, o multicast 224.0.0.102 e timers em milissegundos, e não fala com a versão 1 (Cisco, Configuring HSRP).

IPv6: o gateway é link-local

No IPv6, o primeiro endereço do roteador virtual tem de ser link-local, só o Active Router manda Router Advertisements por ele e os Backups anunciam as mesmas opções (RFC 9568, seções 5.2.9, 6.4.3 e 8.2.3); os hosts o aprendem do jeito de sempre. O host poderia usar o Neighbor Unreachability Detection, mas com os defaults do Neighbor Discovery (ND) "it can take a host more than 10 seconds to learn that a router is unreachable before it will switch to another default router", mais de 10 segundos, contra uns três com o VRRP (seção 1.4). Uma armadilha: se dois roteadores tiverem o mesmo link-local, o FRR avisa que "this can cause both routers to assume the Master role (very bad)", os dois viram Master (documentação do FRRouting, VRRP).

Tracking: a falha que o protocolo não enxerga

Nenhum dos padrões olha além da LAN. A RFC 2281 supõe que todos os roteadores têm rotas consistentes (RFC 2281, seção 1), e a eleição do VRRP só lê prioridades e advertisements. Um roteador sem uplink continua ganhando e encaminha para o que sobrou da tabela.

A resposta é o tracking, recurso dos fabricantes que nenhuma RFC define. A Cisco monitora o line protocol de uma interface ou a alcançabilidade de uma rota, e "By default, the priority of the device is decreased by 10 if a tracked object goes down", a prioridade cai 10 quando o objeto cai (Cisco, Configuring HSRP); sem standby track, não há tracking nenhum. No keepalived, o track_interface baixa a prioridade por um peso negativo configurado (keepalived.conf(5)). Faça a conta: um ativo com 110 que perde 10 empata com um standby de 100, o maior endereço desempata, e pode ser o roteador quebrado; no HSRP, o standby ainda precisa de preemption. Detectar rápido um caminho morto é trabalho do Bidirectional Forwarding Detection (BFD).

Como falha

Dois Active Routers. Se os advertisements deixam de passar entre os roteadores, cada Backup estoura o timeout e vira ativo, e "having multiple Active Routers can cause as much disruption as no routers", vários ativos fazem tanto estrago quanto nenhum (RFC 9568, seção 9). Dois roteadores configurados como owner ficam ativos juntos (errata verificada 8298). Os dois usam o mesmo MAC virtual, que os switches veem pular de porta.
Intervalos diferentes. Um Active Router mais lento que os seus Backups é instável (RFC 9568, seção 5.2.7). Com intervalo zero, todos os Backups estouram o timeout juntos, e o autor da errata verificada 8301 relata "It causes mayhem (I have tried it)!", vira um caos, e ele testou. A Cisco pede os mesmos timers em todo o grupo HSRP (Cisco, command reference).
Timers abaixo de um segundo com carga. Um atraso de fila maior que o intervalo promove um Backup até o advertisement atrasado rebaixá-lo, e "this process can repeat many times per second, causing a significant disruption of traffic", o vaivém se repete várias vezes por segundo (RFC 9568, seção 2.5); o remédio é dar prioridade ao VRRP nas filas de saída.
Preemption em flapping. Um roteador de prioridade maior que vive reiniciando retoma o gateway a cada volta. Nenhuma RFC descreve esse ciclo; os fabricantes oferecem um delay, de 0 segundos por default na Cisco (Cisco, command reference).
O MAC que não muda de lugar. O standby use-bia faz o HSRP usar o burned-in address (BIA) do roteador, e a RFC 2281 diz que "This method of operation is strongly discouraged", fortemente desaconselhado (RFC 2281, seção 6.1): o MAC do gateway muda a cada failover, e os hosts dependem do gratuitous ARP ou de um timeout de cache que a RFC 1122 põe em torno de um minuto (RFC 1122, seção 2.3.2.1).
Caminhos assimétricos. O VRRP pode mandar redirects onde a topologia não é simétrica (RFC 9568, seção 8.1.1); a RFC 2281 proíbe isso no HSRP, porque o redirect revelaria o endereço próprio do roteador (RFC 2281, seção 6.3). Quando as respostas voltam pelo outro roteador, um equipamento stateful num só caminho vê metade de cada conversa.

A superfície de ataque e a defesa

O VRRP antigo oferecia senha em texto ou o IP Authentication Header (RFC 2338, seção 5.3.6), e a RFC 3768 removeu os dois (RFC 3768, seção 13). A RFC 9568 explica: "Operational experience and further analysis determined that these did not provide sufficient security to overcome the vulnerability of misconfigured secrets, causing multiple Active Routers to be elected", a autenticação não compensava os segredos mal configurados, que elegiam vários ativos (RFC 9568, seção 9). Um nó da LAN que anuncia prioridade maior manda os roteadores reais para Backup, e assinatura nenhuma impede um nó de agir como Active Router. Do HSRP, a RFC diz que "The protocol is easily subverted by an active intruder on the LAN", o protocolo é fácil de subverter (RFC 2281, seção 7).

A RFC 9568 relativiza: é um subconjunto do que qualquer nó da LAN já faz (seção 9). A proteção embutida é o TTL 255, que barra injeção vinda de outras redes; o HSRP depende de os roteadores não encaminharem o 224.0.0.2 (RFC 2281, seção 7). A defesa que a RFC 9568 aponta é a porta de acesso: switches que filtram ARP ou ND de portas de host poderiam filtrar o VRRP também (RFC 9568, seção 9).

Como ver

Filtros de captura (pcap-filter(7)):

vrrp                           abbreviation for: ip proto 112
ip6 proto 112                  VRRP over IPv6
udp port 1985                  HSRP
ether host 00:00:5e:00:01:05   frames to or from the virtual MAC of VRID 5

No Wireshark, os filtros de exibição são vrrp e hsrp (Wireshark, campos do vrrp). Um advertisement ilustrativo, com endereços de documentação, gateway 192.0.2.1 e Active Router 192.0.2.2:

Campo	Valor	O que ele diz
Origem	00:00:5e:00:01:05	o MAC virtual do VRID 5
Origem IPv4	192.0.2.2	o endereço próprio do Active Router
Destino, TTL, protocolo	224.0.0.18, 255, 112	VRRP, nunca encaminhado
`vrrp.version`, `vrrp.type`	3, 1	um ADVERTISEMENT do VRRPv3
`vrrp.virt_rtr_id`	5	o VRID
`vrrp.prio`	100	prioridade default; 255 é o owner, 0 é uma saída
`vrrp.short_adver_int`	100	centissegundos: um por segundo
`vrrp.ip_addr`	192.0.2.1	o endereço virtual

Um failover aparece como novo remetente atrás do mesmo MAC, seguido de um gratuitous ARP. No HSRP, chegam hellos do ativo e do standby; leia hsrp.state, hsrp.priority, hsrp.hellotime, hsrp.holdtime e hsrp.virt_ip, ou hsrp2.* na versão 2 (Wireshark, campos do hsrp).

O show vrrp do FRR, num trecho do exemplo da própria documentação, com o alinhamento simplificado (documentação do FRRouting, VRRP):

Virtual MAC (v4)                    00:00:5e:00:01:05
Status (v4)                         Master
Priority                            200
Preempt Mode                        Yes
Master Advertisement Interval (v4)  1000 ms
Skew Time (v4)                      210 ms
Master Down Interval (v4)           3210 ms

No keepalived, as palavras-chave equivalentes são virtual_router_id, priority, advert_int (em segundos), nopreempt e preempt_delay (keepalived.conf(5)). Na Cisco, os comandos, como a command reference os imprime (Cisco, command reference):

standby version {1 | 2}
standby [group-number] preempt [delay {minimum | reload | sync} seconds]
standby track {object-number | interface-type interface-number [decrement priority-decrement]} [shutdown]
standby use-bia [scope interface]

O OUI lookup resolve 00:00:5E:00:01:05 para ", IANA Department", um endereço unicast administrado universalmente; ele não diz VRRP, porque o bloco do VRRP é uma subatribuição dentro do OUI da IANA. O IPv6 Toolkit mostra ff02::12 como multicast de escopo link-local, também sem citar o VRRP. Se dois roteadores discordam, o packet capture plan builder ajuda a posicionar as capturas.

Para lembrar

O gateway é um papel: um VRID, seus endereços e um MAC virtual conhecido, com quem estiver ativo; o owner (prioridade 255) sempre vence.
O host tem de detectar um gateway morto, mas só troca para outro que conheça, e nenhum algoritmo de detecção foi padronizado.
O MAC virtual mantém válido o cache dos hosts; o Active Router o usa como origem dos advertisements para os switches aprenderem a porta.
O VRRPv3 dá o Active Router como morto após três intervalos mais um skew: 3,6094 segundos na prioridade 100 com o intervalo default, menos de 4 para qualquer Backup; os 3 e 10 segundos do HSRP são 2,77 vezes mais lentos.
A preemption vem ligada no VRRP e desligada no HSRP; nenhum percebe a queda de um uplink sem o tracking do fabricante baixar a prioridade o bastante.
O VRRP largou a autenticação porque ela não impede um segundo Active Router; o TTL 255 prende os ataques à LAN, e o filtro nas portas de host os tira das portas não confiáveis.
O padrão atual é a RFC 9568 (abril de 2024), que diz Active Router onde os textos antigos dizem Master; a RFC 2281 é Informational.

Redundância de first hop: VRRP, HSRP e o gateway que é uma ficção

O que o host consegue fazer sozinho

O roteador virtual

Os dois endereços mudam de lugar, e o MAC é o que importa

VRRPv3: o advertisement e a eleição

Os timers, calculados

HSRP: a mesma ideia, outros números

IPv6: o gateway é link-local

Tracking: a falha que o protocolo não enxerga

Como falha

A superfície de ataque e a defesa

Como ver

Para lembrar

Fontes