O VRRP (Virtual Router Redundancy Protocol) permite a utilização de um endereço IP virtual em diferentes Switches/Roteadores. O funcionamento do VRRP é bem simples, dois ou mais dispositivos são configurados com o protocolo para troca de mensagens e então, o processo elege um equipamento MASTER e um ou mais como BACKUP.
Em caso de falha do Roteador VRRP Master o Roteador VRRP Backup assumirá rapidamente a função e o processo ocorrerá transparente para os usuários da rede.
Há também cenários que o roteador Master do VRRP continua ativo, mas não consegue encaminhar os pacotes devido a interface saída (como para a Internet por exemplo) cair. Podemos então fazer o track para o processo VRRP monitorar algum objeto, que pode ser o estado da interface( UP ou down), pingar determinado site, teste de conexão telnet e etc; e dessa forma reduzir a prioridade VRRP baseando-se em uma condição.
A funcionalidade DHCP Relay permite ao Switch L3/Roteador encaminhar as mensagens DHCP em broadcast para determinado servidor além do dominio de broadcast do host, possibilitando assim utilização de um único servidor DHCP para toda a LAN.
Devido ao fato das solicitações de endereço IP ao servidor DHCP ocorrem em broadcast, o roteador configurado com a feature DHCP Relay encaminhará as mensagens ao Servidor DHCP em Unicast.
O servidor DHCP entregará ao cliente o escopo correto baseado na interface IP de origem ( inserida na mensagem DHCP). Para o administrador do servidor DHCP bastará apenas criar os escopos no servidor.
O VRRP (Virtual Router Redundancy Protocol) permite a utilização de um endereço IP virtual em diferentes Switches/Roteadores. O funcionamento do VRRP é bem simples, dois ou mais dispositivos são configurados com o protocolo para troca de mensagens e então, o processo elege um equipamento MASTER e um ou mais como BACKUP.
Em caso de falha do Roteador VRRP Master o Roteador VRRP Backup assumirá rapidamente a função e o processo ocorrerá transparente para os usuários da rede.
Esses dias pesquisando na web sobre protocolos de autoconfiguração para Roteadores HP achei dois artigos bem legais no site abouthpnetworking.com. O site é tão bacana que tenho as vezes vontade e traduzir todos os posts. 😛
A autoconfiguração (autodeploy) descrita nos 2 artigos do abouthpnetworking utilizará as configurações de fábrica do dispositivo que via DHCP irá procurar por um arquivo de configuração e tentar executa-lo.
Apesar dos textos estarem escritos em inglês vale a pena a consulta:
O protocolo VRRP funciona para redundância de Gateway em uma rede, com o objetivo de 2 ou mais roteadores compartilharem o mesmo IP virtual no modo ativo/backup (por padrão).
Para os outros dispositivos da rede, o VRRP permite que o gateway seja visualizado como um único equipamento.
O VRRP é bastante simples em sua função básica: um Roteador é eleito o Master e é responsável pelo encaminhamento do tráfego da rede para os equipamentos que tem aquele o IP Virtual como gateway. O segundo roteador chamado de Backup apenas monitora os pacotes VRRP do barramento. Entretanto, quando o equipamento Master deixar de funcionar, o equipamento Backup assume suas funções como Master.
Os equipamentos configurados com VRRP possuem a sua adminstração de forma individual (Plano de dados e controle separados) e por isso a configuração de rotas e outras features, deverão ser configurada individualmente.
Para um equipamento se eleger como Master é verificado a prioridade (por padrão é 100), vence o roteador que tiver a maior prioridade.
Caso não seja configurada a prioridade do grupo VRRP em um Roteador, o mesmo atribuirá o valor padrão (100) para o equipamento.
Se o endereço IP do Roteador for o mesmo do IP virtual, o equipamento será o MASTER.
Se o Roteador principal falhar, o novo Master será o Roteador Backup com maior prioridade.
VRRP Track
Há também cenários que o roteador Master do VRRP continua ativo, mas não consegue encaminhar os pacotes devido a interface saída (como para a Internet por exemplo) cair. Podemos então fazer o track para o processo VRRP monitorar algum objeto, que pode ser o estado da interface( UP ou down), pingar determinado site, teste de conexão telnet e etc; e dessa forma reduzir a prioridade VRRP baseando-se em uma condição.
No exemplo abaixo, o script demonstrará a redução da prioridade do VRRP do Roteador Master (R2) de forma que quando o link de saída para o Roteador 1 cair, o Roteador Backup (R3) se tornará o Master.
Configuração do VRRP com track
Roteador R2 (Master VRRP)
#
track 1 interface GigabitEthernet0/0/3
! Configurando o track para interface Giga0/0/3
#
interface GigabitEthernet0/0/4
ip address 192.168.32.2 255.255.255.0
vrrp vrid 32 virtual-ip 192.168.32.1
! configurando o grupo VRRP 32 com o IP virtual
vrrp vrid 32 priority 115
! configurando a prioridade do grupo 32 como 110
vrrp vrid 32 track 1 reduced 20
! configurando o track 1 e em caso de falha, ele reduzirá a
! prioridade do VRRP para 95
#
[R2]display vrrp verbose
IPv4 Virtual Router Information:
Running Mode : Standard
Total number of virtual routers : 1
Interface GigabitEthernet0/0/4
VRID : 32 Adver Timer : 100
Admin Status : Up State : Master
Config Pri : 115 Running Pri : 115
Preempt Mode : Yes Delay Time : 0
Auth Type : None
Virtual IP : 192.168.32.1
Virtual MAC : 0000-5e00-0120
Master IP : 192.168.32.2
VRRP Track Information:
Track Object : 1 State : Positive Pri Reduced : 20
Simulando uma falha…
Quando a interface Giga0/0/3 do Roteador R2 falha, o track do VRRP irá identificar a falha e assim reduzir a prioridade do VRRP do Roteador, tornando dessa forma o R3 como Master
! Log do Roteador R2 após a falha na interface Giga0/0/3
%Jul 7 14:37:35:605 2015 R2 VRRP4/6/VRRP_STATUS_CHANGE:
The status of IPv4 virtual router 32 (configured on GigabitEthernet0/0/4) changed from Master to Backup: VRRP packet received.
Output do Roteador R3 após a falha demonstrando a sua eleição como Master
[R3]display vrrp verbose
IPv4 Virtual Router Information:
Running Mode : Standard
Total number of virtual routers : 1
Interface GigabitEthernet0/0/4
VRID : 32 Adver Timer : 100
Admin Status : Up State : Master
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 0
Auth Type : None
Virtual IP : 192.168.32.1
Virtual MAC : 0000-5e00-0120
Master IP : 192.168.32.3
Por padrão a preempção é ativa nos Roteadores e dessa forma quando a interface Giga 0/0/3 do Roteador R2 voltar ao estado UP, o R2 voltará a ser o Master do VRRP.
O protocolo NLB da Microsot (Network Load Balancing) tem como objetivo o balanceamento de tráfego entre um grupo de Servidores utilizando endereços MAC em multicast. Os clientes que acessam os serviços de um grupo de Servidores com NLB, enxergam o serviço de forma transparente.
Para trabalhar com NLB o Switch deve encaminhar o tráfego com destino ao serviço NLB para todos os servidores especificados no cluster NLB e cada servidor filtra o tráfego não desejado.
A cooperação entre o Switch e o protocolo NLB é muito importante e dessa forma é importante saber as maneiras que o protcolo NLB trabalha, que são os modos Unicast e Multicast:
Unicast
No modo unicast, NLB substitui o endereço MAC real de cada servidor no cluster para um endereço comum NLB MAC. Quando todos os servidores no cluster têm o mesmo endereço MAC, todos os pacotes enviados para esse endereço são enviados para todos os membros do cluster. No entanto, um problema com esta configuração é quando os servidores cluster NLB estão conectados ao mesmo switch, você não pode ter duas portas no switch com o registro do mesmo endereço MAC. O protocolo NLB resolve este problema mascarando o endereço MAC do cluster. O Switch olha para o endereço MAC de origem no cabeçalho do quadro Ethernet, a fim de saber quais os endereços MAC são associados com suas portas. O NLB cria um endereço MAC falso e atribui esse falso endereço MAC para cada servidor no cluster NLB. O NLB atribui a cada servidor NLB um endereço MAC falso diferente com base na identificação do membro.
Por exemplo, o endereço MAC do cluster NLB é o 00-bf-ac-10-00-01. O NLB no modo unicast leva o endereço MAC do cluster e, para cada membro do cluster, o NLB muda o segundo octeto do membro NLB. Por exemplo, o servidor 1 terá como falso endereço MAC 00-01-ac-10-00-01, o server com o ID 2 tem o falso endereço MAC 00-02-ac-10-00-01, assim por diante. Se um único endereço MAC está registrado em cada porta do switch, os pacotes não são entregues a todos os membros do cluster, em vez disso os pacotes são enviados para as portas de individuais com base no endereço MAC atribuído a essa porta. Para fazer os quadros serem entregues a todos os membros do cluster, o NLB registra um MAC diferente e utiliza nas mensagens ARP em broadcast. Quando o roteador envia uma solicitação ARP para o endereço MAC do endereço IP virtual, a resposta contém no cabeçalho ARP com o endereço MAC real do cluster NLB 00-bf-ac-10-00-01, como por exemplo citado acima e não o endereço MAC falso.
Os clientes então utilizam o endereço MAC no cabeçalho ARP, não o cabeçalho Ethernet para comunicar-se com o servidor. O switch usa o endereço MAC no cabeçalho Ethernet, não o cabeçalho ARP. A questão é quando um cliente envia um pacote para o cluster NLB com endereço MAC de destino como cluster de endereço MAC 00-bf-ac-10-00-01, o switch olha para a tabela MAC para o endereço MAC 00-bf-ac-10-00-01. Como não há porta registrada com o endereço do cluster NLB 00-bf-ac-10-00-01, o quadro é entregue a todas as portas. Isso força o Switch a encaminhar o quadro para toads as portas ocasionando flooding e atrapalhando o desempenho da rede.
Uma solução para mudar o comportamento de flooding é colocar um hub na frente dos membros do cluster NLB e, em seguida,um uplink do hub para uma porta do switch. Isso evita o problema de duas portas de switch registrando o mesmo endereço MAC. Quando o cliente envia pacotes para o endereço MAC do cluster NLB, os pacotes podem ir diretamente para a porta do switch conectado ao hub e, em seguida, para os membros do cluster NLB.
Multicast
Quando você usa o método de multicast, cada servidor do cluster mantém o endereço MAC original do da placa de rede. Além do endereço MAC original, é também atribuído um endereço MAC em multicast, que é compartilhado por todos os servidores de cluster. As requisições de entrada do cliente são enviadas para todos os servidores do cluster usando o endereço MAC em multicast.
No entanto, no modo multicast, a resposta ARP (ARP reply) enviada por um servidor do cluster em resposta a uma requisição ARP, mapeia o endereço IP unicast do cluster para endereços MAC em multicast. Tal mapeamento no ARP reply é rejeitado por alguns roteadores (ou Switch L3). Dessa forma os administradores devem adicionar uma entrada ARP estática no roteador para mapear o Endereço IP do cluster ao seu MAC Address.
Configurando NLB Multicast mode com o mapeamento estático para Comware
Desabilite a função de validação do ARP.: undo arp check enable
Obs: configure nos Switches L3 e L2 (que os servidores do cluster estejam conectados).
Configure uma entrada estática para o ARP :. arp static ip-address mac-addressvlan-id interface-type interface-number .
Obs: Para Switches com função L3 na topologia.
Configure uma entrada multicast MAC estática: mac-address multicastmac-addressinterfaceinterface-list vlan vlan-id Obs: dependendo do cenário, configure nos Switches L3 (porta para o trunk com o Switch de acesso) e L2 (porta para os servidores)
Resumo
Modo Unicast : O NLB atribui a cada membro de cluster um endereço MAC comum, que é o endereço MAC do cluster e muda o endereço MAC de origem de cada pacote enviado pelos servidores do cluster . Assim, o switch não pode adicionar o endereço MAC do cluster à sua tabela MAC . Dessa forma o endereço MAC é desconhecido e os pacotes destinados ao Cluster são encaminhados para todas as portas do Switch.
Modo Multicast : O NLB usa um endereço MAC multicast que é um endereço MAC virtual para as máquinas do Cluster.
Configuração
No configuration guide do Switch HPN 10500 há uma configuração mais simples sem o mapeamento da entrada ARP no Switch (o link do arquivo de configuração está nas referências abaixo).
O cluster NLB está na VLAN 10 enquanto os clientes estão na VLAN 20. O Switch fará o roteamento entre VLANs e o encaminhamento do tráfego NLB em modo multicast
Obs: iniciaremos a configuração com todas as portas configuradas nas respectivas VLANs e as máquinas utilizando o Switch como gateway
