Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #185016 > unrolled thread

delay the start of a service until LACP negotiation is complete

Back to article view | Back to linux.debian.user

Contents

  delay the start of a service until LACP negotiation is complete "John Ratliff" <jratliff@bluemarble.net> - 2017-08-11 01:10 +0200
    Re: delay the start of a service until LACP negotiation is complete Sven Hartge <sven@svenhartge.de> - 2017-08-11 11:10 +0200
      Re: delay the start of a service until LACP negotiation is complete "John Ratliff" <jratliff@bluemarble.net> - 2017-08-11 15:50 +0200
        Re: delay the start of a service until LACP negotiation is complete Sven Hartge <sven@svenhartge.de> - 2017-08-11 18:40 +0200
          Re: delay the start of a service until LACP negotiation is complete "John Ratliff" <jratliff@bluemarble.net> - 2017-08-11 19:40 +0200
            Re: delay the start of a service until LACP negotiation is complete Sven Hartge <sven@svenhartge.de> - 2017-08-11 19:50 +0200

#185016 — delay the start of a service until LACP negotiation is complete

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.

[toc] | [next] | [standalone]

#185028

John Ratliff <jratliff@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.

[toc] | [prev] | [next] | [standalone]

#185040

<quote who="Sven Hartge">
> John Ratliff <jratliff@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.
>
>

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

[toc] | [prev] | [next] | [standalone]

#185051

John Ratliff <jratliff@bluemarble.net> wrote:
> <quote who="Sven Hartge">
>> John Ratliff <jratliff@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.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#185055

<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.

[toc] | [prev] | [next] | [standalone]

#185056

John Ratliff <jratliff@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.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web