RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1653658 - vlan interface doesn't exists once network target reached
Summary: vlan interface doesn't exists once network target reached
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: radvd
Version: 8.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: 8.0
Assignee: Pavel Zhukov
QA Contact: Ondrej Mejzlik
URL:
Whiteboard:
Depends On: 1652459
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-27 11:19 UTC by Pavel Zhukov
Modified: 2019-06-14 01:14 UTC (History)
20 users (show)

Fixed In Version: radvd-2.17-12.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1652459
Environment:
Last Closed: 2019-06-14 01:14:17 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Pavel Zhukov 2018-11-27 11:19:37 UTC
+++ This bug was initially created as a clone of Bug #1652459 +++

Description of problem:
When configured to serve VLAN interfaces, the radvd unit fails to start at boot.


Version-Release number of selected component (if applicable):
radvd-2.17-10.fc28.x86_64

How reproducible:
Every time.

Steps to Reproduce:
1. Configure radvd to advertise on VLAN interfaces.
2. Reboot.
3. Watch radvd fail to start.

Actual results:
Failed unit startup.

Expected results:
Running radvd.service unit.

Additional info:

--- Additional comment from Ben Herrick on 2018-11-22 02:28:54 EST ---

From journalctl:

Nov 18 14:55:30 xxxx radvd[1191]: version 2.17 started
Nov 18 14:55:30 xxxx radvd[1191]: IPv6 forwarding setting is: 0, should be 1 or 2
Nov 18 14:55:30 xxxx radvd[1191]: IPv6 forwarding seems to be disabled, but continuing anyway
Nov 18 14:55:30 xxxx radvd[1194]: enp2s0.254 not found: No such device

--- Additional comment from Pavel Zhukov on 2018-11-22 06:05:46 EST ---

Hello,

Thank you for the bug report.
It's weird nobody was noticed before. The fix is simple one line patch. I'll submit it upstream

--- Additional comment from Pavel Zhukov on 2018-11-26 10:06:45 EST ---

it's weird I've checked version in rawhide and it works fine. 

#without vlan device:

Nov 26 16:02:45 pzhukov-x240.example.com systemd[1]: Starting Router advertisement daemon for IPv6...
Nov 26 16:02:45 pzhukov-x240.example.com radvd[10087]: version 2.17 started
Nov 26 16:02:45 pzhukov-x240.example.com radvd[10087]: IPv6 forwarding setting is: 0, should be 1 or 2
Nov 26 16:02:45 pzhukov-x240.example.com radvd[10087]: IPv6 forwarding seems to be disabled, but continuing anyway
Nov 26 16:02:45 pzhukov-x240.example.com systemd[1]: Started Router advertisement daemon for IPv6.
Nov 26 16:02:45 pzhukov-x240.example.com radvd[10088]: enp0s25.100 not found: No such device


# sudo ip link add link enp0s25 name enp0s25.100 type vlan id 100

# with vlan device
-- Logs begin at Mon 2018-11-19 10:50:53 CET, end at Mon 2018-11-26 15:57:22 CET. --
Nov 26 15:57:14 pzhukov-x240.example.com systemd[1]: Starting Router advertisement daemon for IPv6...
Nov 26 15:57:14 pzhukov-x240.example.com radvd[9677]: version 2.17 started
Nov 26 15:57:14 pzhukov-x240.example.com radvd[9677]: IPv6 forwarding setting is: 0, should be 1 or 2
Nov 26 15:57:14 pzhukov-x240.example.com radvd[9677]: IPv6 forwarding seems to be disabled, but continuing anyway
Nov 26 15:57:14 pzhukov-x240.example.com systemd[1]: Started Router advertisement daemon for IPv6.


# radvd.conf
interface enp0s25.100
{
// omitted

};

There were not too many changes between f28 and rawhide
Can you please double check your config? 


+* Wed Jun 13 2018 Pavel Zhukov <pzhukov> - 2.17-14
+- Log to stderr in non-daemon mode
+- Add nodaemon option into manpage
+- Re-enable test again
+
+* Mon Jun 04 2018 Pavel Zhukov <pzhukov> - 2.17-12
+- Enable tests and fix them on big endian arches
+
+* Thu Apr 12 2018 Pavel Zhukov <pzhukov> - 2.17-11
+- Enable Werror=all

--- Additional comment from Ben Herrick on 2018-11-26 22:16:18 EST ---

Try adding the VLAN interface using nmcli and then reboot.

The problem does not occur when starting radvd after the system is booted, but radvd will fail because the VLAN interfaces are started _AFTER_ radvd.

--- Additional comment from Ben Herrick on 2018-11-26 22:19:54 EST ---

To be clear, you have to add the VLAN interface permanently in nmcli, also add the configuration for the prefix/interface in /etc/radvd.conf and then reboot in order to observe the behavior.

--- Additional comment from Pavel Zhukov on 2018-11-27 02:52:42 EST ---

(In reply to Ben Herrick from comment #4)
> Try adding the VLAN interface using nmcli and then reboot.
> 
> The problem does not occur when starting radvd after the system is booted,
> but radvd will fail because the VLAN interfaces are started _AFTER_ radvd.

It's different problem and seems like radvd has nothing to do with it but NM brings vlan interface up too late.

[Unit]
Description=Router advertisement daemon for IPv6
After=network.target

--- Additional comment from Beniamino Galvani on 2018-11-27 03:27:20 EST ---

If radvd needs that all connection profiles are activated when it's started, it should depend on the network-online.target in this way:

 After=network-online.target
 Wants=network-online.target

so that it is delayed until NetworkManager has completed the initialization. The NetworkManager-wait-online.service should be active as well.

--- Additional comment from Pavel Zhukov on 2018-11-27 03:50:47 EST ---

(In reply to Beniamino Galvani from comment #7)
> If radvd needs that all connection profiles are activated when it's started,
> it should depend on the network-online.target in this way:
> 
>  After=network-online.target
>  Wants=network-online.target
> 
> so that it is delayed until NetworkManager has completed the initialization.
> The NetworkManager-wait-online.service should be active as well.

Ok. Thanks. Moving back then.
Sorry for the noise

--- Additional comment from Pavel Zhukov on 2018-11-27 03:51:08 EST ---

(In reply to Beniamino Galvani from comment #7)
> If radvd needs that all connection profiles are activated when it's started,
> it should depend on the network-online.target in this way:
> 
>  After=network-online.target
>  Wants=network-online.target
> 
> so that it is delayed until NetworkManager has completed the initialization.
> The NetworkManager-wait-online.service should be active as well.

Ok. Thanks. Moving back then.
Sorry for the noise

--- Additional comment from Fedora Update System on 2018-11-27 06:15:55 EST ---

radvd-2.17-11.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3222e7c914

--- Additional comment from Fedora Update System on 2018-11-27 06:16:37 EST ---

radvd-2.17-16.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b333ac9645


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