Bug 1181097 - keepalived should start after network-online.target instead of network.target
Summary: keepalived should start after network-online.target instead of network.target
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: keepalived
Version: 21
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Ryan O'Hara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-12 11:19 UTC by Artur
Modified: 2015-02-13 17:32 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-13 17:32:04 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Artur 2015-01-12 11:19:11 UTC
Description of problem:

keepalived service is starting too early, before all interfaces have a chance to go up. Then in logs I see this:

Jan 12 11:54:30 r1 Keepalived_vrrp[853]: receive an invalid ip number count associated with VRID!
Jan 12 11:54:30 r1 Keepalived_vrrp[853]: bogus VRRP packet received on eno2 !!!
Jan 12 11:54:30 r1 Keepalived_vrrp[853]: VRRP_Instance(VIP_MGMT) ignoring received advertisment...

Version-Release number of selected component (if applicable):

keepalived-1.2.15-1.fc21.x86_64
Also affects previous versions of Fedora.

How reproducible:

Sometimes (too often), depends on how much time is needed to bring all interfaces up.

Steps to Reproduce:
1. reboot
2. check logs
3.

Actual results:

Jan 12 11:54:30 r1 Keepalived_vrrp[853]: receive an invalid ip number count associated with VRID!
Jan 12 11:54:30 r1 Keepalived_vrrp[853]: bogus VRRP packet received on eno2 !!!
Jan 12 11:54:30 r1 Keepalived_vrrp[853]: VRRP_Instance(VIP_MGMT) ignoring received advertisment...


Expected results:

All required IPs reported by "Netlink reflector" added.

Additional info:

I can fix it by modyfying systemd.service:
Wants=network-online.target
After=syslog.target network-online.target

Probably it could be also avoided by using preempt_delay setting, but I'm using nopreempt in my configuration (can't use both).

Comment 1 Ryan O'Hara 2015-01-12 14:53:52 UTC
Thanks for reporting this. I've never run into this problem myself, but I understand how it would happen. Just one question, why is it that you're seeing a "bogus VRRP packet" message prior to the interface(s) being up? I'm not making the connection.

Comment 2 Artur 2015-01-12 16:28:02 UTC
Those messages appear AFTER network is finally up. Sorry, I should put more steps to reproduce:

1. start master properly
2. reboot backup
3. check backup's logs
4. backup receives announcements from master and logs "bogus VRRP packet" every advert_int seconds.

I should also include earlier log entries:

Jan 12 10:20:08 r1 Keepalived_vrrp[853]: VRRP is trying to assign VIP to unknown vlan107 interface !!! go out and fix your conf !!!
Jan 12 10:20:08 r1 Keepalived_vrrp[853]: VRRP is trying to assign VIP to unknown vlan102 interface !!! go out and fix your conf !!!
(and so on)

I hope it is clear now.

Comment 3 Fedora Update System 2015-01-13 17:56:28 UTC
keepalived-1.2.15-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/keepalived-1.2.15-2.fc20

Comment 4 Fedora Update System 2015-01-13 17:56:34 UTC
keepalived-1.2.15-2.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/keepalived-1.2.15-2.fc21

Comment 5 Ryan O'Hara 2015-01-13 17:58:07 UTC
OK. I've build packages for F20, F21 and Rawhide. Feel free to test and update karma accordingly. Thanks!

Comment 6 Artur 2015-01-19 10:03:17 UTC
Karma updated. Thank You for the fast reaction.

Comment 7 Fedora Update System 2015-01-26 02:27:48 UTC
keepalived-1.2.15-2.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Fedora Update System 2015-01-26 02:30:05 UTC
keepalived-1.2.15-2.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.