0

I'm trying to connect a server with installed Ubuntu-Server to the Internet via Ethernet cable with no success.

Here is the link to the platform we use - https://www.supermicro.com/en/products/system/4u/7049/sys-7049p-trt.cfm

The cable itself is fine (we tested connection on a laptop). When plugged into one of two LAN ports on the server LED slowly flickers green (approx once in 5 seconds).

We tried both Ubuntu-Server 22.04 and 18.04 with same results.

Running ip a command outputs

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 3c:ec:ef:0f:7a:28 brd ff:ff:ff:ff:ff:ff
3: eno2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 3c:ec:ef:0f:7a:29 brd ff:ff:ff:ff:ff:ff

and turning devices eno1 and eno2 off and back on doesn't remedy the situation.

Running ethtool eno1 shows

Settings for eno1:
    Supported ports: [ ]
    Supported link modes:   1000baseT/Full 
                            1000baseKX/Full 
                            10000baseT/Full 
                            10000baseKR/Full 
    Supported pause frame use: Symmetric Receive-only
    Supports auto-negotiation: Yes
    Supported FEC modes: Not reported
    Advertised link modes:  1000baseT/Full 
                            1000baseKX/Full 
                            10000baseT/Full 
                            10000baseKR/Full 
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Speed: Unknown!
    Duplex: Unknown! (255)
    Port: Other
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: off
    Supports Wake-on: g
    Wake-on: g
    Current message level: 0x00000007 (7)
                   drv probe link
    Link detected: no

From what I researched (I looked up this guide https://devicetests.com/troubleshoot-eth0-no-carrier-find-ip-address-ubuntu) seems like NO-CARRIER status from ip a and Link detected: no should mean that cable is disconnected but it's not the case.

Changing speed and duplex through sudo ethtool -s eno1 speed 100 duplex full doesn't work and outputs

Cannot set new settings: Invalid argument
  not setting speed
  not setting duplex

We also checked network controller drivers but seems like they are installed as could be judged from modinfo i40e output

filename:       /lib/modules/4.15.0-156-generic/kernel/drivers/net/ethernet/intel/i40e/i40e.ko
version:        2.1.14-k
license:        GPL
description:    Intel(R) Ethernet Connection XL710 Network Driver
author:         Intel Corporation, <[email protected]>
srcversion:     304E7F43D32C80652A1A2A9
alias:          pci:v00008086d0000158Bsv*sd*bc*sc*i*
alias:          pci:v00008086d0000158Asv*sd*bc*sc*i*
alias:          pci:v00008086d00001588sv*sd*bc*sc*i*
alias:          pci:v00008086d00001587sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D3sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D2sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D1sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D0sv*sd*bc*sc*i*
alias:          pci:v00008086d000037CFsv*sd*bc*sc*i*
alias:          pci:v00008086d000037CEsv*sd*bc*sc*i*
alias:          pci:v00008086d00001589sv*sd*bc*sc*i*
alias:          pci:v00008086d00001586sv*sd*bc*sc*i*
alias:          pci:v00008086d00001585sv*sd*bc*sc*i*
alias:          pci:v00008086d00001584sv*sd*bc*sc*i*
alias:          pci:v00008086d00001583sv*sd*bc*sc*i*
alias:          pci:v00008086d00001581sv*sd*bc*sc*i*
alias:          pci:v00008086d00001580sv*sd*bc*sc*i*
alias:          pci:v00008086d00001574sv*sd*bc*sc*i*
alias:          pci:v00008086d00001572sv*sd*bc*sc*i*
depends:        ptp
retpoline:      Y
intree:         Y
name:           i40e
vermagic:       4.15.0-156-generic SMP mod_unload modversions 
signat:         PKCS#7
signer:         
sig_key:        
sig_hashalgo:   md4
parm:           debug:Debug level (0=none,...,16=all), Debug mask (0x8XXXXXXX) (uint)

Running dhclient -v eno1 shows No DHCPOFFERS received

Also during our research we encountered this thread (https://community.intel.com/t5/Server-Products/NIC-X722-for-10GBASE-T-rev-09-Ubuntu-Server-20-04-02-Can-t/td-p/1286202) that might be similar to our situation. Our setup would correspond to Picture 1 from the original post as our network also uses DHCP. Another similarity is that physically moving the server to another room and/or assigning it a static IP might also be problematic in our case.

Any help would greatly appreciated. Thanks!

Improve this question
1
  • The primary difference in your linked thread between what worked and what didn't was the length of wire in the wall. I know you've checked it, but I'd still suspect the cable - get another one, actually might be good to get it significantly longer than required, and try that. One time when I saw something like this, decades ago, it was card and switch both trying auto-crossover at the same time with the same retry interval; a slightly longer cable might prevent that if that's the problem.
    – tsc_chazz
    Sep 15 at 16:54

2 Answers 2

Reset to default
0

We're having the same problem on 2 servers, one with a quad SFP 10GB X722 card and the other has a dual SFP 10GB X722 card. Any deactivating of a switch port on one of the links will down the other link. They are connected on different switches. It's super odd. Initially we thought it was LACP bonding but it happens without it as well on another basic config host.

We've upgraded the X722 firmware to 6.20 / 1.3357.0 and the hosts are running on a fully patched RHEL8.8.

Waiting for the vendor support ticket to progress, possibly with an explanation from Intel about their card's behavior. Watch this space.

I'm still working on how relevant all these priv flags are, I was going to flip on the lldp flag but it was already on.

driver: i40e
version: 4.18.0-477.21.1.el8_8.x86_64
firmware-version: 6.20 0x80003f39 1.3357.0

# ethtool --show-priv-flags eth0
Private flags for eth0:
MFP                    : off
total-port-shutdown    : off
LinkPolling            : off
flow-director-atr      : on
veb-stats              : off
hw-atr-eviction        : on
link-down-on-close     : off
legacy-rx              : off
disable-source-pruning : off
disable-fw-lldp        : on
rs-fec                 : off
base-r-fec             : off
vf-vlan-pruning        : off
vf-true-promisc-support: off
Improve this answer
0

I had a similar problem with my server.

I just added a cheap USB network adapter for Ubuntu installation. After installation and a full system update, using the USB network adapter, my 10GBase worked fine, so I was able to remove my USB network adapter. The reason for this problem seems to be a bug/error within the Ubuntu installer.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .