Endereços de IP virtual (VIP) do VRRP

O IP virtual do VRRP para dp0bond1 ou dp0bond0, ou VIP, é o endereço IP flutuante que muda do dispositivo principal para o de backup quando ocorre failover. Quando um VRA é implementado, ele tem uma conexão de rede de ligação pública e privada e IPs reais designados em cada interface. Um VIP também é designado em ambas as interfaces, independentemente de o dispositivo ser independente ou estar em um par de HA. O tráfego que tem um IP de destino em sub-redes em VLANs associadas ao VRA é enviado diretamente para esses VIPs do VRRP por meio de uma rota estática no FCR/BCR.

Não é necessário mudar endereços IP virtuais do VRRP para qualquer grupo de gateways nem desativar a interface do VRRP. Esses endereços IP são o método pelo qual o tráfego é roteado para o gateway quando uma VLAN está associada. Como resultado, se eles estiverem inativos, o tráfego de VLAN também estará inativo. Se o endereço IP não estiver presente, então não será possível encaminhar o tráfego do BCR/FCR para o próprio VRA. Esse endereço virtual ou VIP não é mutável neste momento. Essa limitação pode mudar no futuro, mas, atualmente, nem a migração de um VRA entre PODs/FCRs/BCRs nem a mudança do VIP são suportadas.

A seguir, está um exemplo das configurações padrão dos VIPs dp0bond0 e dp0bond1 para um VRA específico. Observe que seus endereços IP e vrrp-groups podem ser diferentes desse exemplo.

set interfaces bonding dp0bond0 vrrp vrrp-group 2 virtual-address '10.127.170.1/26'
set interfaces bonding dp0bond1 vrrp vrrp-group 2 virtual-address '159.8.98.209/29'

Para obter mais informações, consulte Sub-redes de VLAN associadas ao VRRP.

Por padrão, o VRRP é configurado como desativado. Isso assegura que novas provisões e recarregamentos não causem indisponibilidades no dispositivo principal. Para que o tráfego de VLAN funcione, o VRRP deve ser reativado após o fornecimento ou um recarregamento ser concluído. O exemplo a seguir detalha a configuração padrão:

set interfaces bonding dp0bond0 vrrp vrrp-group 2 'disable'
set interfaces bonding dp0bond1 vrrp vrrp-group 2 'disable'

Para ativar o VRRP nessas duas interfaces após uma provisão ou recarregamento, que é necessário para os pares independentes e de HA, execute os comandos a seguir. Em seguida, confirme a mudança:

delete interfaces bonding dp0bond0 vrrp vrrp-group 2 'disable'
delete interfaces bonding dp0bond1 vrrp vrrp-group 2 'disable'

Grupo do VRRP

Um grupo do VRRP consiste em um cluster de interfaces ou interfaces virtuais que fornecem redundância para uma interface primária (ou principal) no grupo. O grupo VRRP define o virtual_router_id na configuração do Keepalive. No próprio protocolo VRRP, ele é referido como o VRID. O grupo do VRRP tem um identificador numérico exclusivo e pode ter até 20 endereços IP virtuais designados.

O ID de grupo do VRRP é designado pela IBM Cloud e não deve ser mudado. Quando um novo grupo de gateway é provisionado além de um Frontend Customer Router (FCR)/Backend Customer Router (BCR) pela primeira vez, ele recebe um grupo VRRP de 1. As provisões subsequentes do grupo de gateways incrementam esse valor para evitar conflitos. Por exemplo, o próximo grupo tem o grupo 2, depois o grupo 3 e assim por diante. Isso é, então, calculado e designado pelo processo de fornecimento. Alterar esse valor arrisca a colisão com outros grupos ativos e, em seguida, a contenção principal/principal, o que provavelmente causa uma indisponibilidade nos grupos de gateway.

Se você migrar de uma configuração anterior, recomenda-se que verifique sua configuração do código para garantir que o ID do grupo do VRRP não seja designado estaticamente.

O ID de grupo do VRRP é persistido no banco de dados, portanto, o mesmo valor de ID do grupo é usado durante um recarregamento ou um upgrade do S.O. Qualquer ID de grupo do VRRP modificado pelo usuário é sobrescrito pelo valor designado pelo sistema durante um recarregamento do S.O.

Prioridade do VRRP

A primeira máquina em um grupo de gateways tem uma prioridade de 254, e esse valor é decrescido para o próximo dispositivo provisionado. Você nunca deve configurar uma prioridade como 255, pois isto define o "proprietário do endereço" VIP e pode resultar em comportamento indesejado quando a máquina é colocada on-line com uma configuração que difere da principal ativa em execução.

Preempção do VRRP

A preempção deve sempre ser desativada em todas as interfaces do VRRP, para que um novo dispositivo ou um que está passando pelo recarregamento de seu SO não tente assumir o cluster.

Intervalo de aviso do VRRP

Para sinalizar que ela ainda está em serviço, a interface principal ou VIF envia pacotes de “pulsação“ chamados “propagandas“ para o segmento de LAN, usando os endereços multicast designados por IANA para o VRRP (224.0.0.18 para IPv4 e FF02:0:0:0:0:0:0:12 para IPv6).

Por padrão, o intervalo é definido como 1. Este valor pode ser aumentado, mas não é recomendado definir um valor acima de 5. Em uma rede ocupada, pode levar muito mais de um segundo para que todos os avisos de VRRP cheguem ao dispositivo de backup principal, portanto, um valor de 2 deve ser usado para redes de alto tráfego.

Sincronização do VRRP (sync-group)

As interfaces em um grupo de sincronização do VRRP (“grupo de sincronização”) serão sincronizadas de modo que, se uma das interfaces no grupo efetuar failover para o backup, todas as interfaces no grupo efetuem failover para o backup. Por exemplo, se uma interface em um roteador principal falhar, o roteador inteiro falhará em um roteador de backup.

Esse valor é diferente do grupo do VRRP, já que ele define quais interfaces em um dispositivo falham quando uma interface nesse grupo registra uma falha. Recomenda-se que todas as interfaces pertençam ao mesmo sync-group; caso contrário, algumas interfaces serão principais e terão IPs de gateway, e outras serão de backup e o tráfego não avançará corretamente mais. Configurações ativo/ativo não são suportadas.

rfc-compatibility do VRRP

A compatibilidade RFC ativa ou desativa endereços MAC RFC 3768 para VRRP em uma interface. Isso deve ser ativado nas interfaces nativas, mas não ativado em quaisquer VIFs configurados. Alguns comutadores virtuais (principalmente VMware) têm problemas com essa ativação e fazem com que o tráfego seja eliminado e não seja enviado para o IP de gateway da máquina host do hypervisor. Deixe essa configuração sozinha e não defina a configuração para nenhum VIF.

Autenticação do VRRP

Se uma senha for configurada para autenticação do VRRP, o tipo de autenticação também deverá ser definido. Se a senha for configurada e o tipo de autenticação não for definido, o sistema gerará um erro ao tentar confirmar a configuração.

Da mesma forma, não é possível excluir a senha do VRRP sem também excluir o tipo de autenticação do VRRP. Se você o fizer, o sistema gerará um erro quando você tentar confirmar a configuração. Se você excluir a senha de autenticação e o tipo de autenticação do VRRP, a autenticação do VRRP será desativada.

O IETF decidiu que a autenticação não deve ser usada para o VRRP versão 3. Para obter mais informações, consulte o RFC 5798 VRRP.

Suporte da Versão 2/3

O VRA suporta ambos os protocolos do VRRP, versão 2 (padrão) e versão 3. Na versão 2, não é possível ter IPv4 e IPv6 juntos; no entanto, na Versão 3, é possível ter IPv4 e IPv6 ao mesmo tempo.

VPN de alta disponibilidade com VRRP

O VRA fornece a capacidade de manter a conectividade por meio de um túnel IPsec usando um parde IBM Cloud® Virtual Router Appliances com VRRP. Quando um roteador falha ou é desativado para manutenção, o novo roteador principal do VRRP restaura a conectividade do Internet Protocol Security entre as redes local e remota.

Ao configurar uma VPN de HA com VRRP, sempre que um endereço virtual do VRRP é incluído em uma interface do VRA, deve-se reinicializar o daemon do Internet Protocol Security porque o serviço do Internet Protocol Security atende apenas a conexões com os endereços que estão presentes no VRA quando o daemon de serviço de troca de chave da Internet (IKE) é inicializado.

Execute o comando a seguir nos roteadores principal e de backup para que, após o failover, os daemons do Internet Protocol Security sejam reiniciados em um novo dispositivo principal após o trânsito do VIP, conforme mostrado no exemplo a seguir:

vyatta@vrouter# set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify ipsec

Firewalls de alta disponibilidade com VRRP

Quando dois dispositivos estão em um par de HA, deve-se tomar cuidado em seu dispositivo principal para que você não bloqueie o acesso do outro dispositivo. A porta 443 deve ser permitida entre os dispositivos para que a sincronização de configuração funcione, e o VRRP deve ser autorizado a ser enviado e recebido, incluindo o intervalo de multicast de 224.0.0.0/24.

Sub-redes de VLAN associadas ao VRRP

Para qualquer configuração do VIF com o VRRP, é necessário um endereço IP virtual (o primeiro IP utilizável na sub-rede, o IP de gateway para o qual tudo nesse sub-rede será roteado) e também um endereço IP de interface real para o VIF nos dispositivos. Para conservar IPs utilizáveis, recomenda-se que os IPs de interface real usem um intervalo fora de banda, como 192.168.0.0/30, em que um dispositivo tem o .1 e o outro dispositivo tem o endereço .2. É possível ter diversos IPs virtuais do VRRP, mas é necessário apenas um endereço real em cada VIF.

Aqui está um exemplo de uma configuração de VRRP com duas VLANs privadas e três sub-redes:

set interfaces bonding dp0bond0 address '10.100.11.39/26'
set interfaces bonding dp0bond0 mode 'lacp'
set interfaces bonding dp0bond0 vif 10 address '192.168.255.81/30'
set interfaces bonding dp0bond0 vif 10 description 'VLAN 10 - Two private subnets/VIPs'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 advertise-interval '1'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 virtual-address '10.100.105.177/28'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 virtual-address '10.100.38.1/26'
set interfaces bonding dp0bond0 vif 11 address '192.168.255.89/30'
set interfaces bonding dp0bond0 vif 11 description 'VLAN 11 - One private subnet/VIP'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 advertise-interval '1'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 virtual-address '10.100.212.65/26'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 'rfc-compatibility'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 virtual-address '10.100.11.5/26'
set interfaces bonding dp0bond1 address '169.110.20.28/29'
set interfaces bonding dp0bond1 mode 'lacp'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify 'ipsec'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 'rfc-compatibility'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 virtual-address '169.110.21.26/29'

• Um grupo de sincronização do VRRP é diferente de um grupo VRRP. Quando uma interface que pertence a um grupo de sincronização mudar de estado, todos os outros membros do mesmo grupo de sincronização serão transicionados para o mesmo estado.
• O número de grupos vrrp das interfaces VLAN (VIFs) deve quase sempre ser o mesmo que sua interface nativa correspondente. Por exemplo, dp0bond1.789 deve sempre ter o mesmo número de grupos vrrp como dp0bond1, a menos que as duas interfaces compartilhem o mesmo grupo de sincronização. Ter um número de grupo diferente no VIF e a interface nativa pode causar uma condição de "cérebro dividido" quando emparelhados com diferentes grupos de sincronização. Quando duas interfaces compartilham o mesmo grupo de sincronização, mesmo que estejam em diferentes grupos de vrrp, elas fazem a transição entre o principal e o backup ao mesmo tempo, evitando o cérebro dividido. Por outro lado, se a interface nativa estiver configurada com um número de grupo de vrrp diferente e um grupo de sincronização diferente como uma interface VLAN, como as sub-redes configuradas nas interfaces de VLAN são estaticamente roteadas para o endereço virtual na interface nativa, se a interface da VLAN estiver sendo mostrada como backup e a interface nativa for a principal, o roteador ainda enviará o tráfego de interface de VLAN para o VRA no qual a interface nativa é principal, embora a interface de VLAN seja secundária e não ativa no VRA. Essa situação específica causa um "split-brain" e uma indisponibilidade. É por isso que é importante estar consciente de como os sync-groups são configurados em conjunto com os grupos de vrrp-groups. Também é importante não usar os mesmos números de vrrp-group entre vários pares de VRA de HA na mesma VLAN de trânsito, uma vez que quatro Vyattas que usam o mesmo grupo fazem com que três VRAs assumam potencialmente o estado de Backup, enquanto apenas um é Principal, causando uma indisponibilidade.
• Os endereços da interface real nas VLANs nativas (por exemplo, dp0bond1: 169.110.20.28/29) nem sempre estão na mesma sub-rede que seus VIPs (169.110.21.26/29).

Failover manual do VRRP

Se for necessário forçar um failover do VRRP, isso poderá ser feito executando o comando a seguir no dispositivo que atualmente é o VRRP principal:

vyatta@vrouter$ reset vrrp master interface dp0bond0 group 1

O ID do grupo é o ID do grupo VRRP das interfaces nativas e, conforme mencionado acima, pode ser diferente em seu par.

Sincronização de conexão

Quando dois dispositivos VRA estão em um par de HA, pode ser útil rastrear conexões stateful entre eles para que, se um failover acontecer, o estado atual de todas as conexões no dispositivo com falha seja replicado para o dispositivo de backup. Não é necessário que sessões ativas atuais (como conexões SSL) sejam reconstruídas do zero, o que pode resultar em uma experiência de usuário interrompida.

Isso é chamado de sincronização de rastreamento de conexão.

Para configurá-la, deve-se declarar qual é o método de failover, qual interface é usada para o envio das informações de rastreamento de conexão, além do IP do peer remoto:

set service connsync failover-mechanism vrrp sync-group SYNC1
set service connsync interface dp0bond0
set service connsync remote-peer 10.124.10.4

O outro VRA tem a mesma configuração, mas um remote-peer diferente.

Observe que isso poderá saturar um link se houver um alto número de conexões sendo recebidas por outras interfaces e haverá competição com outro tráfego no link declarado.

Recurso de atraso de início do VRRP

O S.O. Vyatta versão 1801p e superior inclui um novo comando vrrp.

vrrp especifica um protocolo de eleição que designa dinamicamente a responsabilidade de um roteador virtual a um dos roteadores VRRP em uma LAN. O roteador VRRP que controla os endereços IPv4 ou IPv6 associados a um roteador virtual é chamado de Principal e ele encaminha pacotes que são enviados para esses endereços IPv4 ou IPv6. O processo de eleição fornece failover dinâmico na responsabilidade de encaminhamento, caso o Principal se torne indisponível. Todo o sistema de mensagens de protocolo é executado usando datagramas multicast IPv4 ou IPv6; como resultado, o protocolo pode operar em uma variedade de tecnologias de LAN multiacesso que suportam multicast IPv4/IPv6.

Para minimizar o tráfego de rede, somente o Principal para cada roteador virtual envia mensagens de anúncio periódicas do VRRP. Um roteador de backup não tenta priorizar o Principal, a menos que ele tenha prioridade mais alta. Isso elimina a interrupção do serviço, a menos que um caminho mais preferencial se torne disponível. Também é possível proibir, administrativamente, todas as tentativas de preempção. Se o Principal ficar indisponível, o backup de prioridade mais alta transitará para o Principal após um atraso curto, proporcionando uma transição controlada da responsabilidade do roteador virtual com interrupção mínima do serviço.

Nas implementações provisionadas da IBM Cloud, o valor de atraso de início é configurado para o valor padrão. É possível que você deseje alterar isso a seu critério à medida que você testa seus métodos de failover e alta disponibilidade.

vrrp {
start-delay <0-600>
}

interfaces {
  bonding dp0bond1 {
address 161.202.101.206/29 mode balanced
vrrp {
      start-delay 120
      vrrp-group 211 {
preempt false
priority 253
virtual-address 161.202.101.204/29
} }
}