Comments (4)
pqarmitage
commented on June 2, 2024
It seems quite unlikely that this is caused by Wi-Fi latency. With advert_int 1 and priority 100 a backup instance will transition to master approximately 3.6 seconds after it last received an advert. This would require one advert to be at least 2.6 seconds late, the next at least 1.6 seconds late and the third at least 0.6 seconds late.
I think it would be helpful to run tcpdump on the Raspberry Pi to see what is happening.
from keepalived.
spliff1
commented on June 2, 2024
Looks like some packets are not arriving on the pi. Any way to make keepalived more tolerant ?
22:56 from the Raspberry PI:
Jan 28 22:56:58 raspberrypi Keepalived_vrrp[50987]: (VI_2) Entering MASTER STATE
Jan 28 22:56:58 raspberrypi Keepalived_vrrp[50987]: (VI_2) Master received advert from 192.168.0.51 with higher priority 150, ours 100
Jan 28 22:56:58 raspberrypi Keepalived_vrrp[50987]: (VI_2) Entering BACKUP STATE
tcpdump:
22:56:54.918173 IP (tos 0xc0, ttl 255, id 26724, offset 0, flags [none], proto VRRP (112), length 40)
192.168.0.51 > 192.168.0.154: VRRPv2, Advertisement, vrid 100, prio 150, authtype simple, intvl 1s, length 20, addrs: 192.168.0.2 auth "xx"
22:56:58.528035 IP (tos 0xc0, ttl 255, id 1, offset 0, flags [none], proto VRRP (112), length 40)
192.168.0.154 > 192.168.0.51: VRRPv2, Advertisement, vrid 100, prio 100, authtype simple, intvl 1s, length 20, addrs: 192.168.0.2 auth "xx"
22:56:58.537562 IP (tos 0xc0, ttl 255, id 26728, offset 0, flags [none], proto VRRP (112), length 40)
192.168.0.51 > 192.168.0.154: VRRPv2, Advertisement, vrid 100, prio 150, authtype simple, intvl 1s, length 20, addrs: 192.168.0.2 auth "xx"
22:56:59.543077 IP (tos 0xc0, ttl 255, id 26729, offset 0, flags [none], proto VRRP (112), length 40)
192.168.0.51 > 192.168.0.154: VRRPv2, Advertisement, vrid 100, prio 150, authtype simple, intvl 1s, length 20, addrs: 192.168.0.2 auth "xx"
And from my main server:
Jan 28 22:56:58 web Keepalived_vrrp[2718]: (VI_2) Received advert from 192.168.0.154 with lower priority 100, ours 150, forcing new election
00:13 from the Raspberry PI:
Jan 29 00:13:24 raspberrypi Keepalived_vrrp[50987]: (VI_2) Entering MASTER STATE
Jan 29 00:13:24 raspberrypi Keepalived_vrrp[50987]: (VI_2) Master received advert from 192.168.0.51 with higher priority 150, ours 100
Jan 29 00:13:24 raspberrypi Keepalived_vrrp[50987]: (VI_2) Entering BACKUP STATE
tcpdump:
00:13:21.026025 IP (tos 0xc0, ttl 255, id 31310, offset 0, flags [none], proto VRRP (112), length 40)
192.168.0.51 > 192.168.0.154: VRRPv2, Advertisement, vrid 100, prio 150, authtype simple, intvl 1s, length 20, addrs: 192.168.0.2 auth "xx"
00:13:24.635960 IP (tos 0xc0, ttl 255, id 2, offset 0, flags [none], proto VRRP (112), length 40)
192.168.0.154 > 192.168.0.51: VRRPv2, Advertisement, vrid 100, prio 100, authtype simple, intvl 1s, length 20, addrs: 192.168.0.2 auth "xx"
00:13:24.642360 IP (tos 0xc0, ttl 255, id 31314, offset 0, flags [none], proto VRRP (112), length 40)
192.168.0.51 > 192.168.0.154: VRRPv2, Advertisement, vrid 100, prio 150, authtype simple, intvl 1s, length 20, addrs: 192.168.0.2 auth "xx"
00:13:25.654762 IP (tos 0xc0, ttl 255, id 31315, offset 0, flags [none], proto VRRP (112), length 40)
192.168.0.51 > 192.168.0.154: VRRPv2, Advertisement, vrid 100, prio 150, authtype simple, intvl 1s, length 20, addrs: 192.168.0.2 auth "xx"
And from my main server:
Jan 29 00:13:24 web Keepalived_vrrp[2718]: (VI_2) Received advert from 192.168.0.154 with lower priority 100, ours 150, forcing new election
from keepalived.
pqarmitage
commented on June 2, 2024
This looks as though the Raspberry Pi stops receiving packets and receiving doesn't wake up until after it sends a packet. I suspect that even if you configured keepalived to make it wait 5 and a bit advert intervals for an advert before a backup takes over as master you would still experience the same problem. You can set down_timer_adverts in the vrrp_instance block to 5 (or even a higher value) and see what effect that has (for details see the keepalived.conf(5) man page).
Is it worth slightly repositioning the Pi in case that improves wireless reception? Altering the orientation of the circuit board may help.
from keepalived.
spliff1
commented on June 2, 2024
I've set down_timer_adverts to 5, disabled power saving on the Pi, and enabled IGMP Snooping on the router. I'm still having the same problem. It's weird because if I ping to and from the Pi, I don't have any packet loss in any direction. At this point, I suspect this is related to the integrated Wi-Fi card (signal shouldn't be a problem since the Pi is in the same room with the router - around 3 meters with no obstacle in between)
Thanks for the help!
from keepalived.
Related Issues (20)
- FIFO process seems to be killed prematurely before stop command terminates HOT 5
- After restart NIC, keepalived can not become master state HOT 6
- What is the correct way to disable preempt for keepalived HOT 4
- vrrp_script; Cannot find script docker in path - disabling HOT 3
- The old virtual_ipaddress_excluded has not been deleted after reconfig vlan interface HOT 9
- keepalived Docker Image Build Failed HOT 8
- unable to recover from split brain problem HOT 6
- Configure virtual server only on master but not on backups HOT 5
- v2.2.8: nopreempt is configured, the notify_xxx method will not be triggered. HOT 2
- One-off symlink resolution causes fragile setups on NixOS HOT 6
- Add documentation for notify script option HOT 1
- restart keepalived not work , systemd: Can't open PID file /etc/keepalived/logs/keepalived.pid (yet?) after start: No such file or directory HOT 1
- restart keepalived donot work, Can't open PID file /var/run/keepalived.pid (yet?) after start: No such file or directory HOT 1
- Need to know why both VMs became MASTER instead of a clean failover HOT 6
- Keepalived High Availability Issue: Both Nodes Selected as Master in RHOSP 16.2 Setup HOT 3
- keepalived standby not receiving advertise packets HOT 1
- keepalived can't call notify_master script timely HOT 4
- Last status of misc check sometimes not updated in keepalived_check.data HOT 5
- Do not go to FAULT state when announce link is down HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from keepalived.