Lembrando que neste caso, quando a maquina backup assumir, o mac que vai estar associado ao IP vai ser o da placa de rede dela(não o do CARP - que nunca muda). Seria o mesmo de trocar a placa de rede, se houver algum tipo de segurança de porta no switch, será necessário liberar os 2 MAC(master e backup). Pode haver também uma demora de alguns segundos, até o novo MAC ser aprendido pelo switch e demais equipamentos. Em todos os casos, é bom usar PF + PFSYNC, garantindo que as sessões abertas sejam aprendidas no firewall backup e não haja reset das conexões tcp/udp abertas(PFSYNC e PF não tem nada a ver com carp e IFSTATED, mas sempre é bom fazer esta dobradinha).
Por fim, pode-se usar o ifstated para rodar programas que não foram pensados em esquema de alta disponibilidade. Por exemplo, 2 nagios, um em cada firewall, caso o firewall backup assume, inicia o nagios e por aí vai. Em 14/04/12 09:20, Rafael Ganascim escreveu: > Pessoal, > > Tentem ver a solução CARP + ifstated. Para tal: > > - rodar um processo de carp em OUTRA interface que tenha pelo menos um /29 > - use o IFSTATED para subir os IPs /30 das outras interfaces (pode ser > de todas interfaces /30 com os clientes) de acordo com o estado da > única interface carp (se o carp for MASTER, sobe o /30 em todas > interfaces, se o carp for BACKUP/INIT, derrube os /30 das interfaces > dos clientes). > > É uma solução que funciona, sem precisar sair do carp. Vai existir um > inconveniente se for necessário fazer load sharing entre os > servidores, mas não sei se vem ao caso. > ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
