"Red" network interface down

Support
,
1

NethServer Version: 7.4.1708 (Final)
Module: none (base configuration)

I’m setting up a Nethserver for the first time on a HP ProLiant DL20 Gen9 server. I’ve installed on hardware, not a VM. For reasons I don’t want to get in to right now I needed to install CentOS 7 first [CentOS Linux release 7.4.1708 (Core)] and then install NethServer.
This went well.

The server has two physical network interfaces, so I have one as my “green” interface and that is connected to my LAN. The other is my “red” interface and that is connected to the Internet. So far so good.

The problem started when I tried setting up Active Directory (samba) which needs it’s own IP address and creates a bridge interface. This setup went bad but that’s another topic. What matters here is that the bridge interface (br0) DID get set up correctly – at least I can see it under Configuration -> Network and if I inspect the files in /etc/sysconfig/network-scripts. But the problem is that the “red” interface no longer comes up automatically if the server reboots. I do not see a setting in NethServer’s GUI for enabling/disabling the device. The device appears there and it’s status (DOWN) shows, but I can’t change it. So I log in via SSH and do an “ifup eno2” and this solves the problem until the next reboot.

/etc/sysconfig/network-scripts/ifcfg-eno2 shows this:

DEVICE=eno2
BOOTPROTO=none
GATEWAY=192.168.0.1
IPADDR=192.168.0.2
NETMASK=255.255.255.0
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

So my question is, does NethServer bring up the interfaces or do I need to figure this out in CentOS?

Thanks in advance for any help.

2

You should have a look if there is an error at the messages.log after reboot?
Also you can increase the log-level like explained here:

1 Like
3

I know we encountered such problem in some conditions: CentOS doesn’t bring up the network interface.
There is no clear cause for the issue.

As a workaround, add the ifup command to: /etc/shorewall/started

2 Likes
4

Hi @c_nieu
I tried to debug the same symptoms on an HP server (I don’t recall the model).
I ended up changing the network card.
NethServer uses standard CentOS scripts to activate the card on boot, but I found that sometimes the link was down (logged in /var/log/Messages) and the card had to be “waken up” with
ip link set ensX up

Can you search for similar log lines? Can you reproduce at every boot? Does the above command “solve” the problem?

2 Likes
5

I can confirm this problem, got it on an old Primergy Econel.

I use this Hardware as FreeNAS Storage now…

2 Likes
6

Thanks everyone. /var/log/messages didn’t have anything that pointed to a specific problem but it did report that eno2: link is not ready.

I was able to correct the problem by editing /etc/sysconfig/network-scripts/ifcfg-eno2 and changing BOOTPROTO=none to BOOTPROTO=static

That took care of the problem for me.

2 Likes
7

@c_nieu and @fausp could you please tell us which is chipset of the “guilty” network card?

8

I think it’s a coincidence.
The BOOTPROTO variable can only be set to none or dhcp or bootp.
See /usr/share/doc/initscripts-9.49.39/sysconfig.txt
Setting it to static should produce errors:

9

Found my notes: it was an HP ProLiant ML30 Gen9.
I think it’s quite similar to yours.
The “ip link…” workaround is still in place and working.

10

It was one of this two nics:

em0: <Intel(R) PRO/1000 Network Connection 7.6.1-k> port 0x1820-0x183f mem 0xd8300000-0xd831ffff,0xd8320000-0xd8320fff irq 20 at device 25.0 on pci0
em0: No MSI/MSIX using a Legacy IRQ
em0: Ethernet address: 00:xxxxxxxxxxxxxxxxx
em0: link state changed to UP
em0: link state changed to DOWN
em0: link state changed to UP

re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet> port 0x2000-0x20ff mem 0xd8010000-0xd80100ff irq 22 at device 5.0 on pci1
re0: Chip rev. 0x04000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
re0: Using defaults for TSO: 65518/35/2048
re0: Ethernet address: 00:xxxxxxxxxxxxxxxxx
re0: link state changed to DOWN
11

I’m not disagreeing with you when you say BOOTPROTO=static should produce an error. But in my case changing this line changes the behavior from a non-working system to a working system. I got the idea here (see bullet point 2)
https://wiki.centos.org/FAQ/CentOS7

12

This server has two NICs on the motherboard:
02:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5720 Gigabit Ethernet PCIe
02:00.1 Ethernet controller: Broadcom Limited NetXtreme BCM5720 Gigabit Ethernet PCIe

Both NICs were working correctly (coming up at boot) from time of installation until I installed Samba by configuring my Account Provider to Samba Active Directory. During this process my eno1 interface was converted to a bridge (which worked) and eno2 interface dropped the connection, This caused the Account Provider setup process to fail because without the eno2 interface there was no way to get the RPMs needed. I manually brought up eno2 by issuing ifup eno2 at a command prompt, and then went back and re-started the Account Provider setup. This time it succeeded, presumably because the setup process found the necessary bridge connection was in place and it didn’t need to modify the network configuration this time around. That’s a guess – but the second attempt worked while the first attempt didn’t. But from that point forward, the eno2 interface would not come up on its own after a reboot. Not until I changed BOOTPROTO=none to BOOTPROTO=static in the ifcfg-eno2 configuration file.

13

Good evening to all the same thing happened to me the same thing passing from the ldap provider to active directori the red interface in mode with fixed ip does not work but in dhcp yes
strange