Bug #16322
closed
Gateway monitoring daemon can unexpectedly use a CARP VIP as the source IP address
Added by Christopher Cope 5 months ago.
Updated 20 days ago.
Category:
Gateway Monitoring
Plus Target Version:
25.11
Description
find_interface_ip() in /etc/inc/interfaces.inc has a flush parameter, but that only seems to ignore the $interface_ip_arr_cache.
If the CARP VIP is in /var/db/{$interface}_ip when calling find_interface_ip() with flush the VIP will still be used.
I think it would make sense to add another parameter such as $ignore_cache_file to force the function to reload the current preferred address directly from the interface. This could then be set when calling the function as needed.
This issue was noticed as dpinger was monitoring on the CARP VIP instead of the interface address.
- Status changed from New to Confirmed
I can confirm this behavior, as I've seen the CARP VIP get "stuck" as if it's the primary interface's IP.
Marking Confirmed.
- Status changed from Confirmed to Feedback
- % Done changed from 0 to 100
- Tracker changed from Bug to Todo
- Subject changed from It's possible for the CARP VIP to be preferred in find_interface_ip() to dpinger can use a CARP VIP as the source IP address
- Assignee set to Marcos M
- Target version set to 2.9.0
- Plus Target Version set to 25.11
- Status changed from Feedback to Resolved
Testing this on 25.11 nightlies. I cannot reproduce the CARP VIP being used for dpinger. I've tried several ways of "breaking" it and it seems fixed.
Marking Resolved.
- Subject changed from dpinger can use a CARP VIP as the source IP address to Gateway monitoring daemon can unexpectedly use a CARP VIP as the source IP address
- Tracker changed from Todo to Bug
Also available in: Atom
PDF