Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

delay the start of a service until LACP negotiation is complete

57 views
Skip to first unread message

John Ratliff

unread,
Aug 10, 2017, 7:10:10 PM8/10/17
to
I need two services to wait until the network is fully up before I start
them. In Jessie, I made an rc.local script that pinged google 20 times
until it got a response. After that, it started the services. This seemed
to work great. I upgraded one of the systems to stretch, and the script
stopped working; or at least, I thought it did. Turns out, it just takes
longer under stretch than it did under Jessie (not sure why). Now I need
to do 30 pings to make sure it’s okay.

I’d like a better option. I tried delaying the services until
network-online.target, but this doesn’t really seem to work.

I have a 4 port LAGG (LACP / bond-mode 4) interface named bond0. It seems
to take about 45 seconds after the links come up to negotiate with the
switch. However, as soon as the network gets link active signals on the
individual links, it seems to think the network is up and starts the
services too soon. Is there something I can do to verify the LACP
negotiation is complete before starting some of my services?

Thanks.

Sven Hartge

unread,
Aug 11, 2017, 5:10:05 AM8/11/17
to
John Ratliff <jrat...@bluemarble.net> wrote:

> I have a 4 port LAGG (LACP / bond-mode 4) interface named bond0. It seems
> to take about 45 seconds after the links come up to negotiate with the
> switch.

This long delay is not normal. For me LACP-based bonds never take longer
than 1 or at most 2 seconds to be operational.

This smells of STP. Disable STP on the switch for that port or change to
rSTP.

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

John Ratliff

unread,
Aug 11, 2017, 9:50:06 AM8/11/17
to
<quote who="Sven Hartge">
The ports are trunk ports carrying multiple vlans. I have enabled
spanning-tree portfast trunk on the port channel. It still takes around 5
seconds, but that's significantly faster. However, I have another slight
issue. When conntrackd is started on boot, it gives me some errors:

Aug 11 09:35:30 bltn-firewall-02 conntrackd[1157]: [Fri Aug 11 09:35:30
2017] (pid=1157) [notice] using user-space event filtering
Aug 11 09:35:30 bltn-firewall-02 conntrackd[1157]: [Fri Aug 11 09:35:30
2017] (pid=1157) [notice] netlink event socket buffer size has been set to
262142 bytes
Aug 11 09:35:30 bltn-firewall-02 conntrackd[1157]: [Fri Aug 11 09:35:30
2017] (pid=1157) [notice] initialization completed
Aug 11 09:35:30 bltn-firewall-02 conntrackd[1157]: [Fri Aug 11 09:35:30
2017] (pid=1157) [notice] -- starting in console mode --
Aug 11 09:35:30 bltn-firewall-02 conntrackd[1157]: [Fri Aug 11 09:35:30
2017] (pid=1157) [ERROR] no dedicated links available!

I don't get these errors if I run my delay script. I wonder if this is a
problem.

Thanks.

--John

Sven Hartge

unread,
Aug 11, 2017, 12:40:07 PM8/11/17
to
John Ratliff <jrat...@bluemarble.net> wrote:
> <quote who="Sven Hartge">
>> John Ratliff <jrat...@bluemarble.net> wrote:

>>> I have a 4 port LAGG (LACP / bond-mode 4) interface named bond0. It
>>> seems to take about 45 seconds after the links come up to negotiate
>>> with the switch.

>> This long delay is not normal. For me LACP-based bonds never take
>> longer than 1 or at most 2 seconds to be operational.
>>
>> This smells of STP. Disable STP on the switch for that port or change
>> to rSTP.

> The ports are trunk ports carrying multiple vlans. I have enabled
> spanning-tree portfast trunk on the port channel. It still takes around 5
> seconds, but that's significantly faster.

Do you really need STP? Do you really need STP on that group of ports?
Why not disable it completely.

> However, I have another slight issue. When conntrackd is started on
> boot, it gives me some errors:

> Aug 11 09:35:30 bltn-firewall-02 conntrackd[1157]: [Fri Aug 11 09:35:30 2017] (pid=1157) [notice] using user-space event filtering
> Aug 11 09:35:30 bltn-firewall-02 conntrackd[1157]: [Fri Aug 11 09:35:30 2017] (pid=1157) [notice] netlink event socket buffer size has been set to 262142 bytes
> Aug 11 09:35:30 bltn-firewall-02 conntrackd[1157]: [Fri Aug 11 09:35:30 2017] (pid=1157) [notice] initialization completed
> Aug 11 09:35:30 bltn-firewall-02 conntrackd[1157]: [Fri Aug 11 09:35:30 2017] (pid=1157) [notice] -- starting in console mode --
> Aug 11 09:35:30 bltn-firewall-02 conntrackd[1157]: [Fri Aug 11 09:35:30 2017] (pid=1157) [ERROR] no dedicated links available!

> I don't get these errors if I run my delay script. I wonder if this is a
> problem.

I have the same, but the systemd.unit restarts conntrackd automatically
if it dies, so there is no problem.

If you use systemd-networkd to control your interfaces, you could enable
systemd-networkd-wait-online.service and have conntrackd depend on
network-online.target to make it start _after_ the network is really
online.

Unfortunately ifupdown got this feature only after the release of
Stretch.

John Ratliff

unread,
Aug 11, 2017, 1:40:05 PM8/11/17
to
<quote who="Sven Hartge">
> Do you really need STP? Do you really need STP on that group of ports?
> Why not disable it completely.

I'm not aware of any way to disable spanning tree on a per port basis, and
no, I cannot disable it on the switch entirely.

>
> I have the same, but the systemd.unit restarts conntrackd automatically
> if it dies, so there is no problem.
>
> If you use systemd-networkd to control your interfaces, you could enable
> systemd-networkd-wait-online.service and have conntrackd depend on
> network-online.target to make it start _after_ the network is really
> online.
>
> Unfortunately ifupdown got this feature only after the release of
> Stretch.

I tried this, as I am on stretch, but I get the same errors as before. If
you don't think they're a problem, I will leave it be for now.

Thanks.

Sven Hartge

unread,
Aug 11, 2017, 1:50:05 PM8/11/17
to
John Ratliff <jrat...@bluemarble.net> wrote:
> <quote who="Sven Hartge">

>> Do you really need STP? Do you really need STP on that group of
>> ports? Why not disable it completely.

> I'm not aware of any way to disable spanning tree on a per port basis,
> and no, I cannot disable it on the switch entirely.

Ah, Cisco. Yes, they don't do that, right.


0 new messages