Unraid Network Issues


Recommended Posts

So I have been having problems with running Live TV through Plex and would swear up and down it was a Plex issue.  I would check logs of Plex and constantly encounter issues where Live TV (communication between Plex and HD Homerun device) would stutter.  I was believing this was a Plex/HD Homerun device but then I started thinking about my server dropping my mapped network drives among other "odd" occurances like when using PuTTy where it just seems to have trouble on the network.  I decided to run Live TV while monitoring server logs and the second my live tv started stuttering, there are the logs that appear in Unraid.  I am starting to believe this isn't a plex issue but some sort of network issue related to either Unraid or my hardware.  I know this isn't the typical format of providing logs but I wanted to provide the specifics that occurs to the issue.  I can provide additional diagnostics if necessary but wasn't sure if something stood out from the below.  For reference, server ip is 192.168.1.119 (which I am sure is clear below).    Thanks in advance fro your help.  

 

Oct 20 11:56:57 HawkinsUnraid kernel: pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:04:00.0
Oct 20 11:56:57 HawkinsUnraid kernel: igb 0000:04:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID)
Oct 20 11:56:57 HawkinsUnraid kernel: igb 0000:04:00.0: device [8086:1533] error status/mask=00004000/00000000
Oct 20 11:56:57 HawkinsUnraid kernel: igb 0000:04:00.0: [14] CmpltTO
Oct 20 11:56:57 HawkinsUnraid kernel: bond0: (slave eth0): link status definitely down, disabling slave
Oct 20 11:56:57 HawkinsUnraid kernel: device eth0 left promiscuous mode
Oct 20 11:56:57 HawkinsUnraid kernel: bond0: now running without any active interface!
Oct 20 11:56:57 HawkinsUnraid kernel: br0: port 1(bond0) entered disabled state
Oct 20 11:56:57 HawkinsUnraid kernel: pcieport 0000:00:1c.5: AER: device recovery successful
Oct 20 11:56:58 HawkinsUnraid dhcpcd[2125]: br0: carrier lost
Oct 20 11:56:58 HawkinsUnraid avahi-daemon[12196]: Withdrawing address record for 192.168.1.119 on br0.
Oct 20 11:56:58 HawkinsUnraid avahi-daemon[12196]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.1.119.
Oct 20 11:56:58 HawkinsUnraid avahi-daemon[12196]: Interface br0.IPv4 no longer relevant for mDNS.
Oct 20 11:56:58 HawkinsUnraid dhcpcd[2125]: br0: deleting route to 192.168.1.0/24
Oct 20 11:56:58 HawkinsUnraid dhcpcd[2125]: br0: deleting default route via 192.168.1.1
Oct 20 11:56:58 HawkinsUnraid dnsmasq[15575]: no servers found in /etc/resolv.conf, will retry
Oct 20 11:56:59 HawkinsUnraid ntpd[2200]: Deleting interface #4820 br0, 192.168.1.119#123, interface stats: received=28, sent=28, dropped=0, active_time=229 secs
Oct 20 11:56:59 HawkinsUnraid ntpd[2200]: 216.239.35.0 local addr 192.168.1.119 -> <null>
Oct 20 11:56:59 HawkinsUnraid ntpd[2200]: 216.239.35.4 local addr 192.168.1.119 -> <null>
Oct 20 11:56:59 HawkinsUnraid ntpd[2200]: 216.239.35.8 local addr 192.168.1.119 -> <null>
Oct 20 11:56:59 HawkinsUnraid ntpd[2200]: 216.239.35.12 local addr 192.168.1.119 -> <null>
Oct 20 11:57:01 HawkinsUnraid kernel: igb 0000:04:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Oct 20 11:57:01 HawkinsUnraid kernel: bond0: (slave eth0): link status definitely up, 1000 Mbps full duplex
Oct 20 11:57:01 HawkinsUnraid kernel: bond0: (slave eth0): making interface the new active one
Oct 20 11:57:01 HawkinsUnraid kernel: device eth0 entered promiscuous mode
Oct 20 11:57:01 HawkinsUnraid dhcpcd[2125]: br0: carrier acquired
Oct 20 11:57:01 HawkinsUnraid kernel: bond0: active interface up!
Oct 20 11:57:01 HawkinsUnraid kernel: br0: port 1(bond0) entered blocking state
Oct 20 11:57:01 HawkinsUnraid kernel: br0: port 1(bond0) entered forwarding state
Oct 20 11:57:02 HawkinsUnraid dhcpcd[2125]: br0: rebinding lease of 192.168.1.119
Oct 20 11:57:06 HawkinsUnraid dhcpcd[2125]: br0: probing address 192.168.1.119/24
Oct 20 11:57:11 HawkinsUnraid dhcpcd[2125]: br0: leased 192.168.1.119 for 86400 seconds
Oct 20 11:57:11 HawkinsUnraid dhcpcd[2125]: br0: adding route to 192.168.1.0/24
Oct 20 11:57:11 HawkinsUnraid dhcpcd[2125]: br0: adding default route via 192.168.1.1
Oct 20 11:57:11 HawkinsUnraid avahi-daemon[12196]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.119.
Oct 20 11:57:11 HawkinsUnraid avahi-daemon[12196]: New relevant interface br0.IPv4 for mDNS.
Oct 20 11:57:11 HawkinsUnraid avahi-daemon[12196]: Registering new address record for 192.168.1.119 on br0.IPv4.
Oct 20 11:57:11 HawkinsUnraid dnsmasq[15575]: reading /etc/resolv.conf
Oct 20 11:57:11 HawkinsUnraid dnsmasq[15575]: using nameserver 192.168.1.1#53
Oct 20 11:57:12 HawkinsUnraid ntpd[2200]: Listen normally on 4821 br0 192.168.1.119:123
Oct 20 11:57:12 HawkinsUnraid ntpd[2200]: new interface(s) found: waking up resolver

Link to comment

I also figured it might be beneficial to show my Unraid network settings.  See picture:  I'll note I am confused why I have two Interfaces?  I am in no way a technical expert with networking (equipment) but confused on why I have eth0 and eth1 that use the same MAC address.  I did "Port Down" the eth1 interface as reflected in the image; however, I still got the issue noted above after that change.  

image.thumb.png.7be8761432a03df230af2685d4ce4484.png

Link to comment

...you are running a bonded interface, in active backup mode, build from your two Intel based NICs.

Apparently one of these is having problems and when that happens, the active member of the bond will switch over to the other NIC.

 

You need to find out what is actualy killing the link.

Does this happen to only the first NIC or does this also happen to the other one?

You could try by changing the enumeration, by swapping the MAC addresses for eth0 and eth1.

unraid will normally use eth0 as the default, active NIC.

 

The first line of your log indicates that this is not a cabling issue but an issue with your PCI(e) interface the NIC sits on.

Also, the Address for both NICs indicate, that these are not on the same BUS address, hence not a DUAL card.

Try to disable ASPM in BIOS for the NICS and/or PCIe.

 

If the one(s) that fail are on a external card, try to use/deploy into a different slots.

 

 

 

Edited by Ford Prefect
Link to comment
3 hours ago, Ford Prefect said:

...you are running a bonded interface, in active backup mode, build from your two Intel based NICs.

Apparently one of these is having problems and when that happens, the active member of the bond will switch over to the other NIC.

 

You need to find out what is actualy killing the link.

Does this happen to only the first NIC or does this also happen to the other one?

You could try by changing the enumeration, by swapping the MAC addresses for eth0 and eth1.

unraid will normally use eth0 as the default, active NIC.

 

The first line of your log indicates that this is not a cabling issue but an issue with your PCI(e) interface the NIC sits on.

Also, the Address for both NICs indicate, that these are not on the same BUS address, hence not a DUAL card.

Try to disable ASPM in BIOS for the NICS and/or PCIe.

 

If the one(s) that fail are on a external card, try to use/deploy into a different slots.

 

 

 

Thanks.  I guess I'll check out Board BIOS settings.  I'll note that this is not an external card.  All NIC's would be integrated with the mobo.  I have no separate cards.  For reference the Mobo is a Supermicro X12SCZ-F.   I know there is a bios update out there for it -- i'll contact Supermicro to see if it relates to the NIC's.  I'm always hesitant on the bios updates.  

 

Also, I didn't know I had two NIC's.  I took a quick look at the Mobo specs and guess you are right.  It shows:

Network Controllers:

Single LAN with Intel® PHY I219LM LAN controller

Single LAN with Intel® Ethernet Controller I210-AT

 

Which actually makes sense because I have 3 network ports in the rear i/o:   IPMI (Supermicro), LAN2, and LAN1.  I am currently only using the LAN2 port.

 

Would you also suggest switching to the LAN1 port and using that?  Or wiring both up to the switch?  Like i said, I am horrible with my knowledge of networking and am amateur at best :).  Thanks for your help and time in responding!  Note that LAN2 seems to be linked to the 5E:B5 mac address in my picture above.  LAN1 is linked to 5E:B4 which again is not wired into my network switch.

Edited by Hawkins12
Link to comment

Ah, yes...you are right.
It is always the same NIC that is failing and then recovering again. It is the one named eth0, running the Intel igb driver, from your picture above.

Check the bios, especially energy saving features (often called ASPM) and try disabling these...if possible, only for the NICs.

You can test the second, if this will behave better, as it uses a different driver in Linux/unraid (e1000e).

If you only want to deploy a single link (bond with active backup mode will allow for higher availability, as it will switch over in case of a problem) you could disable bonding in unraid config. Should you keep it, deploy both ports with a patch cable to your switch.

Gesendet von meinem SM-G780G mit Tapatalk

  • Thanks 1
Link to comment
3 hours ago, Ford Prefect said:

Ah, yes...you are right.
It is always the same NIC that is failing and then recovering again. It is the one named eth0, running the Intel igb driver, from your picture above.

Check the bios, especially energy saving features (often called ASPM) and try disabling these...if possible, only for the NICs.

You can test the second, if this will behave better, as it uses a different driver in Linux/unraid (e1000e).

If you only want to deploy a single link (bond with active backup mode will allow for higher availability, as it will switch over in case of a problem) you could disable bonding in unraid config. Should you keep it, deploy both ports with a patch cable to your switch.

Gesendet von meinem SM-G780G mit Tapatalk
 

Thanks so much for these.  Def. going to try these when i get home from business travel.  Appreciate your help and time!

Link to comment
  • 2 weeks later...
On 10/21/2021 at 12:22 PM, Ford Prefect said:

Ah, yes...you are right.
It is always the same NIC that is failing and then recovering again. It is the one named eth0, running the Intel igb driver, from your picture above.

Check the bios, especially energy saving features (often called ASPM) and try disabling these...if possible, only for the NICs.

You can test the second, if this will behave better, as it uses a different driver in Linux/unraid (e1000e).

If you only want to deploy a single link (bond with active backup mode will allow for higher availability, as it will switch over in case of a problem) you could disable bonding in unraid config. Should you keep it, deploy both ports with a patch cable to your switch.

Gesendet von meinem SM-G780G mit Tapatalk
 

 

So I am still testing this but I did not mess with bios settings just yet.  I did plug another ethernet cord from the 2nd LAN spot to the switch and it seemed to have made a difference.  I havent had the issue for two days.  Perhaps i have a bad NIC?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.