"igb1: link state changed to UP/DOWN" is it benign ?

chudak

I noticed in the log somewhat often messages like:

Feb 25 11:36:03	kernel		igb1: link state changed to UP
Feb 25 11:35:59	kernel		igb1: link state changed to DOWN
Feb 25 10:54:48	kernel		igb1: link state changed to UP
Feb 25 10:54:45	kernel		igb1: link state changed to DOWN
Feb 25 09:53:13	kernel		igb1: link state changed to UP
Feb 25 09:53:09	kernel		igb1: link state changed to DOWN
Feb 25 09:51:22	kernel		igb1: link state changed to UP
Feb 25 09:51:18	kernel		igb1: link state changed to DOWN
...

igb1 is my LAN, wonder is this is something to worry about and maybe there is a way to suppress it?

Any clues appreciated !
@jimp

chudak

More logs:

Feb 26 21:01:55	php-fpm	31922	/rc.linkup: Hotplug event detected for LAN(lan) static IP (192.168.90.1 )
Feb 26 21:01:54	check_reload_status	378	Linkup starting igb1
Feb 26 21:01:54	kernel		igb1: link state changed to UP
Feb 26 21:01:51	check_reload_status	378	Reloading filter
Feb 26 21:01:51	php-fpm	31922	/rc.linkup: Hotplug event detected for LAN(lan) static IP (192.168.90.1 )
Feb 26 21:01:50	kernel		igb1: link state changed to DOWN
Feb 26 21:01:50	check_reload_status	378	Linkup starting igb1
Feb 26 19:47:04	arpwatch	85578	bogon 10.10.10.1 00:0e:c4:d1:6f:28
Feb 26 19:47:03	check_reload_status	378	Reloading filter
Feb 26 19:47:03	php-fpm	70483	/rc.newwanip: rc.newwanip: on (IP address: 192.168.90.1) (interface: LAN[lan]) (real interface: igb1).
Feb 26 19:47:03	php-fpm	70483	/rc.newwanip: rc.newwanip: Info: starting on igb1.
Feb 26 19:47:02	check_reload_status	378	Reloading filter
Feb 26 19:47:02	check_reload_status	378	rc.newwanip starting igb1
Feb 26 19:47:02	php-fpm	70483	/rc.linkup: Hotplug event detected for LAN(lan) static IP (192.168.90.1 )
Feb 26 19:47:01	check_reload_status	378	Linkup starting igb1
Feb 26 19:47:01	avahi-daemon	97939	Leaving mDNS multicast group on interface igb1.IPv4 with address 192.168.90.1.
Feb 26 19:47:01	avahi-daemon	97939	Withdrawing workstation service for igb1.
Feb 26 19:47:01	avahi-daemon	97939	Withdrawing address record for 192.168.90.1 on igb1.
Feb 26 19:47:01	avahi-daemon	97939	Withdrawing address record for 10.10.10.1 on igb1.
Feb 26 19:47:01	kernel		igb1: link state changed to UP
Feb 26 19:46:59	check_reload_status	378	Reloading filter
Feb 26 19:46:59	php-fpm	11509	/rc.linkup: Hotplug event detected for LAN(lan) static IP (192.168.90.1 )
Feb 26 19:46:58	kernel		igb1: link state changed to DOWN
Feb 26 19:46:58	check_reload_status	378	Linkup starting igb1
Feb 26 19:09:31	arpwatch	85578	bogon 10.10.10.1 00:0e:c4:d1:6f:28

JKnott

@chudak

Check your Ethernet cables & switch. If you're getting those errors, it indicates a problem in that area.

chudak

@jknott said in "igb1: link state changed to UP/DOWN" is it benign ?:

@chudak

Check your Ethernet cables & switch. If you're getting those errors, it indicates a problem in that area.

Replaced the cable and changed ports will see, thx !

JKnott

@chudak

If you have a managed switch, it might also have logs.

chudak

@jknott said in "igb1: link state changed to UP/DOWN" is it benign ?:

@chudak

If you have a managed switch, it might also have logs.

I don't :(

So far was not sure if i need it or not.

But so far I see no errors in the log since made the change :)

Thx !

chudak

Kept it in my amazon cart

https://www.amazon.com/gp/product/B07GRG63P6/ref=ox_sc_saved_title_8?smid=ATVPDKIKX0DER&psc=1

Is it a good choice?

JKnott

@chudak

Link errors refer to problems with the hardware or cables and have nothing to do with IP or pfsense. This limits you to the NIC, cables or switch. Cables are the most likely cause. After running a while without error, try moving back to the original port. It's probably OK. Then toss the old cable.

JKnott

@chudak said in "igb1: link state changed to UP/DOWN" is it benign ?:

https://www.amazon.com/gp/product/B07GRG63P6/ref=ox_sc_saved_title_8?smid=ATVPDKIKX0DER&psc=1

Avoid TP-Link. Some models don't handle VLANs properly. If you're not planning on using VLANs, it's probably OK, but there are other brands in the same price range that don't have the VLAN problem.

However, a managed switch isn't necessary unless you want to use VLANs etc.

chudak

@jknott said in "igb1: link state changed to UP/DOWN" is it benign ?:

@chudak

Check your Ethernet cables & switch. If you're getting those errors, it indicates a problem in that area.

So far it did not work, still see errors :(

JKnott

@chudak

Well, it has something to do with the Ethernet connection. That means the NIC, cable or switch. How often does it happen? Any pattern?

chudak

@jknott

It's possible that I am paying more attention to the logs after 2.5.0, I see no "visible" problems.

See the frequency here:

Feb 27 12:03:52	kernel		igb1: link state changed to UP
Feb 27 12:03:49	kernel		igb1: link state changed to DOWN
Feb 27 10:19:28	kernel		igb1: link state changed to UP
Feb 27 10:19:24	kernel		igb1: link state changed to DOWN
Feb 27 09:07:20	kernel		igb1: link state changed to UP
Feb 27 09:07:16	kernel		igb1: link state changed to DOWN
Feb 27 09:03:58	kernel		igb1: link state changed to UP
Feb 27 09:03:55	kernel		igb1: link state changed to DOWN
Feb 27 07:00:56	kernel		igb1: link state changed to UP
Feb 27 07:00:52	kernel		igb1: link state changed to DOWN
Feb 27 03:41:55	kernel		igb1: link state changed to UP
Feb 27 03:41:52	kernel		igb1: link state changed to DOWN
Feb 27 03:20:36	kernel		igb1: link state changed to UP
Feb 27 03:20:32	kernel		igb1: link state changed to DOWN
Feb 27 02:53:23	kernel		igb1: link state changed to UP
Feb 27 02:53:19	kernel		igb1: link state changed to DOWN
Feb 27 00:33:20	kernel		igb1: link state changed to UP
Feb 27 00:33:16	kernel		igb1: link state changed to DOWN
Feb 26 23:57:50	kernel		igb1: link state changed to UP
Feb 26 23:57:46	kernel		igb1: link state changed to DOWN
Feb 26 22:01:58	kernel		ovpns1: link state changed to UP
Feb 26 22:01:58	kernel		ovpns1: link state changed to DOWN
Feb 26 21:01:54	kernel		igb1: link state changed to UP
Feb 26 21:01:50	kernel		igb1: link state changed to DOWN
Feb 26 19:47:01	kernel		igb1: link state changed to UP
Feb 26 19:46:58	kernel		igb1: link state changed to DOWN
Feb 26 19:09:28	kernel		igb1: link state changed to UP
Feb 26 19:09:25	kernel		igb1: link state changed to DOWN
Feb 26 16:05:55	kernel		igb1: link state changed to UP
Feb 26 16:05:51	kernel		igb1: link state changed to DOWN
Feb 26 14:24:08	kernel		igb1: link state changed to UP
Feb 26 14:24:05	kernel		igb1: link state changed to DOWN
Feb 26 11:02:24	kernel		igb1: link state changed to UP
Feb 26 11:02:20	kernel		igb1: link state changed to DOWN

See no obvious pattern...

The port and cable were changed around Feb 27 09:07

JKnott

@chudak

Those do seem frequent and it appears the link goes down for 3-4 seconds. Do you notice any effect when this happens? Does it show in the switch or NIC lights?

I just checked my system and haven't seen a link change since around noon yesterday, when I was doing some testing with openvpn. That would be around 29.5 hours since the last one. As an experiment, I just tried connecting and disconnecting my test LAN NIC to my notebook. Here's the result:

Feb 26 12:04:57 firewall kernel: ovpns1: link state changed to UP
Feb 27 17:32:10 firewall kernel: igb2: link state changed to UP
Feb 27 17:32:10 firewall kernel: igb2: link state changed to DOWN
Feb 27 17:32:11 firewall php-fpm[349]: /rc.linkup: DEVD Ethernet attached event for opt2
Feb 27 17:32:11 firewall php-fpm[349]: /rc.linkup: HOTPLUG: Configuring interface opt2
Feb 27 17:32:14 firewall kernel: igb2: link state changed to UP
Feb 27 17:32:15 firewall php-fpm[348]: /rc.linkup: DEVD Ethernet detached event for opt2
Feb 27 17:32:15 firewall php-fpm[51629]: /rc.linkup: DEVD Ethernet attached event for opt2
Feb 27 17:32:15 firewall php-fpm[51629]: /rc.linkup: HOTPLUG: Configuring interface opt2
Feb 27 17:32:17 firewall kernel: igb2: link state changed to DOWN
Feb 27 17:32:20 firewall php-fpm[349]: /rc.linkup: DEVD Ethernet detached event for opt2

I included one line from when I was testing my VPN, so you can see how long I went without any link state messages. This also shows what happens with a complete disconnection of the Ethernet cable.

Are you running any packages that might affect the connections?

chudak

@jknott

I need to keep my eye on this, so far I didn’t see any related problems, or at least did not register them as such

Don’t see much lights issues but I’m not watching my switch all the time

Run all standard packages

No errors in last ~4 h

Interesting...

chudak

@jknott

Update - I see no link state changed messages on LAN since yesterday.

What changed? I reinstalled all packages after seeing some warnings in the log.

However I see now this on WG:

Feb 28 09:09:40	kernel		wg0: link state changed to UP
Feb 28 09:09:40	kernel		wg0: link state changed to DOWN
Feb 28 09:09:39	kernel		wg0: link state changed to UP
Feb 28 09:09:39	kernel		wg0: link state changed to DOWN
Feb 28 09:09:38	kernel		wg0: link state changed to DOWN
Feb 27 12:03:52	kernel		igb1: link state changed to UP

The fact that this is on wg0 makes me think it maybe s/w related not cables etc.

JKnott

@chudak

You're running Wireguard and OpenVPN?

chudak

@jknott said in "igb1: link state changed to UP/DOWN" is it benign ?:

@chudak

You're running Wireguard and OpenVPN?

Yes

chudak

@jknott

Still see them:

Mar 20 07:20:31	check_reload_status	378	Reloading filter
Mar 20 07:20:31	check_reload_status	378	rc.newwanip starting igb1
Mar 20 07:20:31	php-fpm	74793	/rc.linkup: Hotplug event detected for LAN(lan) static IP (192.168.90.1 )
Mar 20 07:20:30	kernel		igb1: link state changed to UP
Mar 20 07:20:30	check_reload_status	378	Linkup starting igb1
Mar 20 07:20:27	check_reload_status	378	Reloading filter
Mar 20 07:20:27	php-fpm	71393	/rc.linkup: Hotplug event detected for LAN(lan) static IP (192.168.90.1 )
Mar 20 07:20:26	kernel		igb1: link state changed to DOWN
Mar 20 07:20:26	check_reload_status	378	Linkup starting igb1
Mar 20 06:52:21	arpwatch	79456	bogon 10.10.10.1 00:0e:c4:d1:6f:28
Mar 20 06:52:20	check_reload_status	378	Reloading filter

and nothing else ...
:( ???

stephenw10

Try swapping the LAN to a different port. Something other than igb1.

Steve

chudak

@stephenw10

Yeah that's probably only an option left.
Current assignment:
LAN - igb1

I do have igb3 NIC/port available.

Would you assign a new LAN2 -> igb3 (and then copy all FW rules to it)
or
is it safe simply change LAN -> igb3 ?

and connect an Ethernet cable to a new port after...

PS: Trying to make sure not to do anything stupid :)

Thx