HA on ESXI 6.5 - not working properly. Please help



  • I have 2 VMs connected to VDS. VDS connected to LAG, Promiscuous mode , MAC address changes and Forged transmits configured to Accept. All sync work properly, but when master is down i have no connection, ping timeout and i need to start ping again. I found information about Net.ReversePathFwdCheckPromisc and i need . to set it to 1, but it seems this option only for 6.0 not for 6.5. What else should I set up, so as not to lose connection when changing the gateway from the master to backup



  • I set Net.ReversePathFwdCheckPromisc to 1, reboot hosts, reset all "MAC address changes and Forged transmits configured to Accept" from accept to reject and back - no chanse. No redundancy ((



  • Updateto 6.7, set Net.ReversePathFwdCheckPromisc to 1, reset MAC address changes and Forged transmits to Accept. No chance. Very strange, in the same switch Cisco ASA work properly.



  • Other strange - when i put master in "persistent CARP maintenance mode" - all work properly, but when I stop master - ping is stoping. Magic...



  • @alexniko same issue here; I have no VDS but simply standard switches; I have it previously working on Esxi 5.5.
    When the second node become master, it is impossible to ping an address outside the lan; I verified however, that if I ping from the command interface of the second node I can ping an address on the WAN and also seen that if I set on a machine a gateway with the address of the lan on the second node, I have no problem to exit on the wan; so it seems that when the carp is activated the routing is broken.

    Any suggestion is welcome.



  • @alexniko said in HA on ESXI 6.5 - not working properly. Please help:

    Other strange - when i put master in "persistent CARP maintenance mode" - all work properly, but when I stop master - ping is stoping. Magic...

    I haven't noticed it previously..uaoooo, it's magic :-) but it is also very annoying :-(



  • @alexniko said in HA on ESXI 6.5 - not working properly. Please help:

    Other strange - when i put master in "persistent CARP maintenance mode" - all work properly, but when I stop master - ping is stoping. Magic...

    I also notice this: I've seen in the arp table the mac associated with the VIP and take not of this on the master, then disabled the master and take note on the new master node and the mac was different; what I noticed is that the nic (not the vip) of the new master takes the same mac as the vip of the old master; so I have, for example:

    On master:

    • wan_vip_ip that has mac 00:0c:29:1e:69:43
    • wan_ip_master mac 00:0c:29:2f:f7:64

    When the second node becomes master:

    • wan_vip_ip mac becomes 00:00:5e:00:01:01
    • wan_ip_master mac becomes 00:0c:29:1e:69:43

    So, to test, I put the master in persistent CARP mode and when I accessed the arp table I noticed that there is no more vip ip address and mac in the list.

    After this, I resumed the first node from persistent CARP and visit the arp table page that, I don't know why, doesn't show anymore the ip and mac of the vip.

    Sincerely, I don't understand this behavior, because I supposed that the vip has the same ip but also the same mac, but in the first test it is not as I show.
    Could you see what is your arp table and do some tests?



  • Other things found is this:
    Virtual Router MAC Address

    As stated, the virtual router mac address starts with 00-00-5e, so in my previous post it seems that on the master node there was a "strange" mac address: but why it all works with the "strange" mac on the wan while when there is a "correct" mac on vip on the node became master it seems that the routing doesn't work?



  • Thanks to all. All done. The reason is missunderstanding of paradigma )))



  • Sorry,
    could you explain better and also how do you resolved? I still have the issue.

    Thanks.



  • @alexniko finally I resolved. I reinstalled the system some times ago and have not checked the promiscuous mode on Wan interface.
    So lesson learned is check, check and check again.