Symptoms & scope
- The interface is administratively up but has NO-CARRIER or link detected: no.
- Repeated link-down/up events coincide with connection drops or speed renegotiation.
Relevant environment
Physical Ethernet NICs; virtual interfaces, bridges and optical links have different operational-state and module requirements.
Recognizable messages (synthetic examples)
e1000e 0000:00:19.0 enp0s25: NIC Link is DownIt can also occur during deliberate interface closure. Only unexplained drops correlated with loss of connectivity justify physical-link investigation.
Possible causes
These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.
- Cable pairs, connectors, a switch port, power or a transceiver can prevent the lower-layer link from working.
- An unsupported optical module or incompatible link-mode configuration can matter on particular NICs; lack of an IP address alone is not a carrier diagnosis.
Diagnose safely
Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.
Check 1
Replace IFACE with the physical Ethernet NIC. Read administrative flags, carrier-related flags, state and master membership without bringing it up or down.
ip -details link show dev IFACEInterpret the result: UP means administratively enabled; LOWER_UP indicates the driver’s lower-layer signal. An interface enslaved to a bridge may receive its IP configuration on the bridge instead.
Check 2
Replace IFACE with that NIC. Query supported and advertised modes, speed, duplex and link detection; privileges may be required for some hardware queries.
ethtool IFACEInterpret the result: Link detected: no confirms no reported physical link at that time. Compare advertised modes with the switch; unknown speed with no link is expected and is not a DHCP error.
Evidence-guided next steps
Compare cable and switch port separately
If carrier is absent or flaps without intentional disconnects, compare one known-good appropriate cable on the same port, then a known-good switch port in a separate test. Check switch power and link indicators to determine whether the fault follows the path.
Precautions: Record VLAN and port policy before moving the cable; the alternate port may belong to another network. Physical changes interrupt active sessions.
Recovery / rollback: Reconnect the original cable and port if the comparison loses the expected VLAN or management path.
Did this solution help you?
Restore supported link negotiation
If the profile or switch shows a manually forced incompatible speed/duplex setting, save both ends’ settings and restore the link mode recommended for that hardware. For ixgbe or another optical NIC, verify the exact transceiver/cable support in the driver and hardware documentation.
Precautions: Do not force one end to full duplex while the other negotiates an incompatible mode, or bypass module validation blindly. Use local or out-of-band access before changing a management link.
Recovery / rollback: Restore the saved NIC and switch settings together and return the original supported transceiver/cable if negotiation worsens.
Did this solution help you?
References & review
This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.
- Linux kernel: administrative and operational link states (project or distribution documentation)
- Debian ethtool manual: driver, link and statistic queries (project or distribution documentation)
- Linux kernel: ixgbe hardware and link requirements (project or distribution documentation)
- Linux e1000e: hardware hang and carrier messages, source snapshot (upstream implementation; behavior can vary by version)