pqarmitage
commented
2 years ago The logs from your backup indicate that you have not provided your complete configuration, since the entries refer to line numbers that don't exist in the configuration you have provided. If you are using ip rules, then you are using policy routing, and that could well relate to the cause of your problem. Indeed, the log messages state that there are missing priorities in the ip rule statements, and so keepalived has used a default priority, and indicated that that may not be what you want.
You are using VMACs and also unicast peers; this doesn't really make sense. If you use VMACs when you should just let keepalived multicast. Also I would remove the vmac_xmit_base.
If you can reach the VIP from the host on which it is configured but not from other hosts on the same LAN, then that suggests it is probably a firewall issue, either on the host where you are running keepalived or on the hosts from which you are trying to connect. When I have these problems I tend to use tcpdump or wireshark ti identify where the packets are being blocked. I also find it can be useful to add firewall rules without any action, e.g.
iptables -I INPUT -s YYY.YYY.YYY.YYY -d XXX.XXX.XXX.10
and then you can inspect the counters to see if matching packets are traversing the rule.
First of all I would try removing nginx from the setup and just try pinging the VIP. If that still doesn't work then I suggest you try without running keepalived and manually setting up the ip rules/routes/addresses and get that working. Once that is working then update the keepalived configuration to make sure that it is setting up the same ip rules/routes/addresses as the manual configuration you created.
If you post your manually created ip rules/routes/addresses that work, we can assist in translating those into the keepalived configuration.
Alternatively you could post the output of:
ip rule
ip routeFor each table listed in the ip rule output:
ip route list table nnn
And finally:
ip address
If you obfuscate any addresses etc, you will need to change them to valid address (e.g. 10.1.2.3) maintaining the appropriate subnet structure so that we can understand what is happening.
You should not need to add any iptables entries, or change any sysctl values, unless your existing iptables configuration is stopping what you are doing from working, or your existing sysctl values have been changed from defaults.
I am closing this issue since it is not a keepalived issue but rather a network configuration issue, but you will still be able to update the issue and we can respond further.
Zarkaouette
Describe what you need help/support for I'm using VMs in Azure and running reverse-proxy (nginx) on 2 instances. As it is PROD, I need this RP functionnality to be highly-available and then decided to go with Keepalived. After installing/configuring in a MASTER/BACKUP fashion, I'm able to reach the VIP only locally to the MASTER node. If I manually failover the BACKUP node as a MASTER, then again I can reach the service on the VIP locally to the node but not from any other machine located in the same LAN.
Details of what you would like to do with keepalived When I start the keepalived process and have the VIP attributed to a node, it should be accessible from any other VM/device within the same network
Keepalived version v2.0.19 (10/19,2019)
Distro (please complete the following information):
Details of any containerisation or hosted service (e.g. AWS) Both NGINX (RP) and KEEPALIVED are running directly on the host, no containerisation is used, no hosted service.
Configuration file: MASTER Configuration :
The BACKUP node has the exact same configuration except for the "state" and "priority"
Notify and track scripts Content of the "check_nginx":
Logs on the MASTER
Logs on the BACKUP
So far it's ok.
From MASTER :
From another machine in the same LAN (here from BACKUP) :
As already described, if I stop NGINX on the MASTER, then BACKUP node becomes MASTER. Then, I can observe the same thing : I'm able to curl from the new MASTER on the VIP but not from any other nodes.
I tried playing around IPTABLES and many other options (net.ipv4.conf.all.arp_ignore, net.ipv4.conf.all.arp_annouce, virtual_routes etc...) but nothing seems to work. Any of you guys have any ideas ?