Inconsistent but frequent NIC errors NIC Link is Down / Up

So thinking through if this is normal or not and how to test it, I ran a ping with a timestamp.

 

First the error (yet another one), then the ping.

 

Apr 23 17:12:13 Obi-Wan kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Down

Apr 23 17:12:13 Obi-Wan kernel: br0: port 1(eth0) entered disabled state

Apr 23 17:12:15 Obi-Wan kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX

Apr 23 17:12:15 Obi-Wan kernel: br0: port 1(eth0) entered blocking state

Apr 23 17:12:15 Obi-Wan kernel: br0: port 1(eth0) entered forwarding state

 

Tue Apr 23 17:12:09 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=191 ttl=64 time=0.472 ms

Tue Apr 23 17:12:10 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=192 ttl=64 time=0.440 ms

Tue Apr 23 17:12:11 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=193 ttl=64 time=0.176 ms

Tue Apr 23 17:12:12 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=194 ttl=64 time=0.194 ms

Tue Apr 23 17:12:16 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=198 ttl=64 time=0.144 ms

Tue Apr 23 17:12:17 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=199 ttl=64 time=0.274 ms

Tue Apr 23 17:12:18 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=200 ttl=64 time=0.270 ms

Tue Apr 23 17:12:19 NZST 2019: 64 bytes from 192.168.43.3: icmp_seq=201 ttl=64 time=0.416 ms

 

You can see, while the NIC was down at 17:12:13 to 17:12:15, pings stopped (see 17:12:12 then 17:12:16.

 

Coincidence?  I don't think so.  Whether this makes much of a difference to anything I don't know, but I could see in an online game how having the network down for four whole seconds might wreak some havoc.

I've now powered down and up the switch (which didn't work), and have now just tried enabling flow control on the switch port - probably not working but because Unraid seems to have pause on in RX mode.  Tomorrow will try another cable and another NIC.  I'm thinking it's software though.

"link is down" is more likely a hardware issue.

• Check or replace cables
• Use a different NIC
• Use a different switch port
• Use a different switch

I've already checked cables, changed the switch port, I still can't try a new NIC because CrashPlan and it's block sync is on it's third day sigh and stopping it would be beginning from the beginning!  I think it will be finished tomorrow.  I have my doubts about the switch being an issue, I can check on another linux box if it is having a similar issue, but I doubt it.  Thanks for your input, will try card next.

I have something similar in my logs, it's been going on under 6.6.7 prior to me updating to 6.7.0-rc7. It happens several times a day. I recently switched both the switch that Unraid is connected to and the ethernet card, but I'm seeing similar messages both before and after I switched the hardware.

 

Apr 23 10:42:24 unRAID kernel: docker0: port 5(veth36c9b86) entered blocking state

Apr 23 10:42:24 unRAID kernel: docker0: port 5(veth36c9b86) entered disabled state

Apr 23 10:42:24 unRAID kernel: device veth36c9b86 entered promiscuous mode

Apr 23 10:42:24 unRAID kernel: IPv6: ADDRCONF(NETDEV_UP): veth36c9b86: link is not ready

Apr 23 10:42:24 unRAID kernel: docker0: port 5(veth36c9b86) entered blocking state

Apr 23 10:42:24 unRAID kernel: docker0: port 5(veth36c9b86) entered forwarding state

Apr 23 10:42:24 unRAID kernel: docker0: port 5(veth36c9b86) entered disabled state

Apr 23 10:42:24 unRAID kernel: eth0: renamed from vethaf1be8e

Apr 23 10:42:24 unRAID kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth36c9b86: link becomes ready

Apr 23 10:42:24 unRAID kernel: docker0: port 5(veth36c9b86) entered blocking state

Apr 23 10:42:24 unRAID kernel: docker0: port 5(veth36c9b86) entered forwarding state

Apr 23 10:42:27 unRAID kernel: docker0: port 6(vethe876c38) entered blocking state

Apr 23 10:42:27 unRAID kernel: docker0: port 6(vethe876c38) entered disabled state

Apr 23 10:42:27 unRAID kernel: device vethe876c38 entered promiscuous mode

Apr 23 10:42:27 unRAID kernel: IPv6: ADDRCONF(NETDEV_UP): vethe876c38: link is not ready

Apr 23 10:42:27 unRAID kernel: docker0: port 6(vethe876c38) entered blocking state

Apr 23 10:42:27 unRAID kernel: docker0: port 6(vethe876c38) entered forwarding state

Apr 23 10:42:27 unRAID kernel: docker0: port 6(vethe876c38) entered disabled state

 

Apr 23 14:57:29 unRAID kernel: br0: port 3(vnet1) entered blocking state

Apr 23 14:57:29 unRAID kernel: br0: port 3(vnet1) entered disabled state

Apr 23 14:57:29 unRAID kernel: device vnet1 entered promiscuous mode

Apr 23 14:57:29 unRAID kernel: br0: port 3(vnet1) entered blocking state

Apr 23 14:57:29 unRAID kernel: br0: port 3(vnet1) entered forwarding state

 

I was going to get around to asking the question at some point if these messages matter. I have not had any noticeable performance or network issues so it hasn't been a priority.

 

 

 

 

2 hours ago, italeffect said:

I was going to get around to asking the question at some point if these messages matter. I have not had any noticeable performance or network issues so it hasn't been a priority.

These messages come from Docker, harmless and expected.

Thanks.  Yes, I think those are different as with yours there is not a primary network connection going down and up, whereas with mine, I think it is.

6 hours ago, Marshalleq said:

I've already checked cables, changed the switch port, I still can't try a new NIC because CrashPlan and it's block sync is on it's third day sigh and stopping it would be beginning from the beginning!  I think it will be finished tomorrow.  I have my doubts about the switch being an issue, I can check on another linux box if it is having a similar issue, but I doubt it.  Thanks for your input, will try card next.

Reseating (or moving) the NIC may help too.

Intel NICs are the most commonly used in Unraid and work well.

It’s onboard. I’m going to add a pci dual Nic by intel tomorrow though.