Storage

Dell EMC ECS – Useful commands to check network links

By July 24, 2023September 12th, 2026No Comments

A node is unreachable, or a swarm of disks went suspect at the same moment, and the question is whether this is storage or cabling. These commands read the network links across every ECS node from one shell — read-only, nothing changes. Written against ECS 3.x on Gen3 EX-series hardware; on Gen1 and Gen2 nodes there are no pslave-* interfaces, only the slave-* front-end pair.

Which network links are up, on every node at once

admin@ecs-n01:~> viprexec -i 'ip link show | egrep "slave-|public"'

Output from host : 192.168.219.1
2: pslave-0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master private state UP mode DEFAULT group default qlen 1000
3: pslave-1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master private state UP mode DEFAULT group default qlen 1000
4: slave-0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master public state UP mode DEFAULT group default qlen 1000
5: slave-1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq master public state DOWN mode DEFAULT group default qlen 1000
...

(Output trimmed to one node — the real thing repeats per node.)

Three things to read in that output:

  • pslave-* is the back end, slave-* is the front end. The p is for private: those are the interfaces the nodes use to talk to each other, bonded into private. The slave-* pair is bonded into public and carries client traffic.
  • The MTU is a useful tell, but only a tell. Here the back end runs jumbo frames at 9000 and the front end the default 1500 — but jumbo frames on the public side are supported, so on a cluster where someone enabled them both bonds read 9000. Use the interface name, not the MTU, when it matters.
  • NO-CARRIER with state DOWN on slave-1 above means the interface is administratively up and the cable is not carrying — unplugged, dead optic, or the switch port is shut. That is the line you are looking for.

Link detected: no — checking link state with ethtool

admin@ecs-n01:~> viprexec "sudo ethtool slave-0 | egrep 'Settings|Link detected'; sudo ethtool slave-1 | egrep 'Settings|Link detected'; sudo ethtool pslave-0 | egrep 'Settings|Link detected'; sudo ethtool pslave-1 | egrep 'Settings|Link detected'"

Output from host : 192.168.219.1
Settings for slave-0:
        Link detected: yes
Settings for slave-1:
        Link detected: no
Settings for pslave-0:
        Link detected: yes
Settings for pslave-1:
        Link detected: yes

Same information as the first command, in a form that is much easier to scan across twenty blocks of output when you are checking network links on a full rack. Link detected: no is the one to grep for.

Which switch and which port

admin@ecs-n03:~> sudo lldpcli show neighbor
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    pslave-0, via: LLDP, RID: 4, Time: 24 days, 20:36:14
  Chassis:
    ChassisID:    mac d8:9e:f3:xx:xx:xx
    SysName:      sw-01
    SysDescr:     Dell EMC Networking OS10-Enterprise.
                  OS Version: 10.4.3.6C1.
                  System Type: S5148F-ON
    Capability:   Bridge, on
  Port:
    PortID:       ifname ethernet1/1/3
    PortDescr:    ethernet1/1/3

This is the command that saves the walk to the rack. For each interface it names the switch and the port on the other end, so "which switch port is this" has an answer before anyone walks to the rack. For a whole cluster at once, Dell's own one-liner is the readable form:

admin@ecs-n01:~> viprexec -i "sudo lldpcli show neigh | egrep 'SysName|PortID'"

cabling matches the design — a back-end interface whose neighbour is a front-end switch is a mis-patch, and it will behave like an intermittent fault until someone looks.

If an interface is missing from the output entirely, either the link is down or LLDP is not enabled on that switch port.

And ip link tells you an interface is up; it does not tell you the bond took it. After a node reboot a slave-x or pslave-x can come back healthy on its own and still be left out of the aggregation — check cat /proc/net/bonding/public and /proc/net/bonding/private for the slave list before concluding the link is fine. Dell's first remediation for a link that should be up is sudo ethtool -r <interface> to force renegotiation, before anyone touches hardware.

What the port actually is

admin@ecs-n01:~> sudo ethtool slave-0
Settings for slave-0:
        Supported ports: [ FIBRE ]
        Supported link modes:   10000baseT/Full
        Speed: 10000Mb/s
        Duplex: Full
        Port: Direct Attach Copper
        Auto-negotiation: off
        Link detected: yes

Speed and duplex are worth a glance on a link that works but performs badly. Note Auto-negotiation: off here — on direct-attach copper the speed is forced rather than negotiated, so a wrong value points at the module or the driver, not at a failed handshake.

ethtool -m: what is plugged in, and "Cannot get module EEPROM information"

admin@ecs-n01:~> sudo ethtool -m slave-0
        Identifier                                : 0x03 (SFP)
        Connector                                 : 0x21 (Copper pigtail)
        Transceiver type                          : Infiniband: 1X Copper Passive

-m reads the module EEPROM: what kind of transceiver is in the cage, and on optics, the measured light levels. On a link that flaps rather than fails, that is where the evidence is.

admin@ecs-n01:~> sudo ethtool -m slave-1
Cannot get module EEPROM information: Invalid argument

That error is not a fault by itself. The usual cause is that there is nothing in the cage to read. Two others are worth knowing: some passive DACs do not expose a readable EEPROM, and some drivers return this exact message until the NIC firmware is updated — Intel's X710/XXV710 family is the known case. On this node slave-0 read back cleanly through the same driver, so here it points at an empty cage.

Read it with the link state: an empty cage and no carrier is a port with nothing plugged in at the node end — a cable unplugged at the far end would still report its module.

Why this matters beyond the network

A batch of disks going SUSPECT at the same time on one node is usually not a disk problem — Dell attributes swarms of suspect disks to connectivity at the node, and says they return to Good once that is fixed. That makes the network links the first thing to check when the ECS failed-disk checks come back strange, rather than an unrelated topic. If the cabling is clean and the disk really is dead, replacing a faulted disk is the next stop.

Leave a Reply

Share