[Moved to Roadmap] LLDP support in TrueNAS Scale

Feature Requests
,
1

Problem/Justification
LLDP support was deprecated in TrueNAS Scale 22 or 23. LLDP is commonly used to discover critical resources (beyond network devices) across an enterprise network.

Impact
TrueNAS users will not be directly impacted by this feature. The feature primarily benefits network administrators or SREs that are responsible for determining the current state of the network. (Re)-implementing this feature will address a deficiency in TrueNAS SCALE that is expected of critical resources on a network (e.g., a storage appliance). There are no obvious disadvantages to re-implementing this feature.

User Story
A network administrator/SRE/etc. (not a TrueNAS user) will provide the data expected to be received from an LLDP-capable device. The information that the TrueNAS device will send will be incorporated into an operational model that describes the current state/configuration of the network.

Reference
This request was created as recommended from the “LLDP in TrueNAS Scale” thread in TrueNAS General.

3 Likes
2

https://ixsystems.atlassian.net/browse/NAS-127982

1 Like
3

This is definitely a necessary feature in any serious network environment. We need it to monitor link layer information.

4

Question:

If LLDP was provided without being plumbed into middleware and UI would that be adequate?

User would have to use CLI to enable/configure . Perhaps done via a post-boot script.

If not, what UI needs are there?

5

Just look at the implementation in CORE. You have all the code.

On, off, possibly restrict interfaces, possibly select LLDP only, CDP, etc.

All of this was part of your product. And it’s trivial.

1 Like
6

Just checking if its worthwhile to add LLDP only via CLI… that would be simpler and faster and require no testing. If its not worthwhile it will take longer.

7

How do you enable or disable a CLI only service? Doesn’t TrueNAS replace the entire startup with something middleware controlled?

Also do you really want to go the Proxmox route where the answer to everything blatantly missing from the UI is “just use the commnd line, it’s Linux”?

I thought TrueNAS had a general “stay away from the CLI” approach.

8

Without taking away from the request – this is easy to do yourself with docker. On my system with apps in /mnt/tank/apps:

Dockerfile: put in /mnt/tank/apps/lldp/build

FROM debian:trixie-slim

RUN apt-get update && \
    apt-get install -y --no-install-recommends lldpd && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

CMD ["lldpd", "-d"]

docker-compose.yaml:

services:
  server:
    build: /mnt/tank/apps/lldpd/build
    cap_add:
      - NET_ADMIN
      - NET_RAW
    command: # see lldp(8) manpage
      - lldpd
      - '-d'
      - '-I' # interfaces to listen on
      - eno1
      - '-C' # interface to use for chassis ID
      - eno1
    network_mode: host
    restart: unless-stopped
    uts: host

Result:

admin@switch> show lldp neighbors detail    
LLDP Neighbor Information:
Local Information:
Index: 7 Time to live: 120 Time mark: Sun Oct 12 01:35:02 2025 Age: 20 secs 
Local Interface    : ge-0/0/2
Parent Interface   : -
Local Port ID      : 515
Ageout Count       : 0

Neighbour Information:
Chassis type       : Mac address
Chassis ID         : 01:23:45:67:89
Port type          : Mac address
Port ID            : 01:23:45:67:89
Port description   : eno1
System name        : truenas
  
System Description : Debian GNU/Linux 13 (trixie) Linux 6.12.33-production+truenas #1 SMP PREEMPT_DYNAMIC Mon Sep 29 18:41:19 UTC 2025 x86_64

System capabilities 
        Supported: Bridge WLAN Access Point Router Station Only 
        Enabled  : Bridge Router 

Management address 
        Address Type      : IPv4(1)
        Address           : 192.168.1.10
        Interface Number  : 2
        Interface Subtype : ifIndex(2)

Organization Info
       OUI      : IEEE 802.3 Private (0x00120f)
       Subtype  : Link Aggregation (3)
       Info     : Aggregation Status [supported, disabled (0x1)], Aggregation Port ID (0)
       Index    : 1                     

Organization Info
       OUI      : IEEE 802.3 Private (0x00120f)
       Subtype  : MAC/PHY Configuration/Status (1)
       Info     : Autonegotiation [supported, enabled (0x3)], PMD Autonegotiation Capability (0x6c83), MAU Type (0x1e)
       Index    : 2
1 Like
9

@Evan123 - Perhaps iX needs to make a supported LLDP App. Then people who want / need this just install it as an App.

1 Like
10

Interesting! Thanks!

It still won’t communicate with snmpd via agentx that way, but it’s a first step.

I probably do not understand how this build process works - Dockge always complained about not being able to find the context /mnt/nvme/apps/lldpd …

But I found this ready made image: GitHub - DE-IBH/lldpd-docker: Docker image for lldpd based on the offical Debian packages.

services:
  lldpd:
    image: ibhde/lldpd
    cap_add:
      - NET_ADMIN
      - NET_RAW
    network_mode: host
    hostname: truenas.mydomain.lan
    command:
      - -I
      - eno*
    environment:
      - TZ=Europe/Berlin
networks: {}
11

You can pass the agentx socket into the container – mount the directory above the socket (/var/agentx?) into the container. You can also install any programs you may need by adding more to the Dockerfile. The container is also running with host networking so it can access all the network ports on the host.

I don’t use dockge, but with docker-compose you should have been able to put the Dockerfile (exact case) in the exact directory specified by build: – see Compose Build Specification | Docker Docs.

12

Seems to work:

services:
  lldpd:
    image: ibhde/lldpd
    cap_add:
      - NET_ADMIN
      - NET_RAW
    network_mode: host
    hostname: truenas.mydomain.lan
    command:
      - -x
      - -I
      - eno*
    environment:
      - TZ=Europe/Berlin
    volumes:
      - /var/agentx:/var/agentx
networks: {}
1 Like
13

It’s a good way to deliver any functionality above the OS so the OS stays simple and clean, and parts can be changed independently. Maybe a T3 question: are there future plans for TrueNAS to use containers for itself?

14

Strongly disagree. Removing core functions from a data centre appliance OS and referring to “you can add that in docker” is not fostering confidence in their ability to deliver a data centre capable product in the first place.

SNMP and LLDP are ubiquitous. At least in my data centre world. Maybe the latter is lesser known because most people think “CDP” instead. So yes, let’s have CDP (Cisco Discovery Protrocol) then. Almost all implementations that speak the generic standard also speak Cisco’s proprietary version.

Come on … VMware speaks CDP. Your switches do. The storage layer should, too. And did in TN CORE.

Wasn’t the claim that enterprise customers do not run apps or VMs? And now everything is relegated to apps? Custom ones, even. :roll_eyes:

Kind regards,
Patrick

2 Likes
15

See also, SMART.

1 Like
16

You must have missed the next sentence: Maybe a T3 question: are there future plans for TrueNAS to use containers for itself?

17

Great news! This feature request has been transferred to our internal roadmap for detailed scoping and assessment.

What this means:

  • Our product and technical documentation team will now evaluate technical feasibility, resource requirements

  • This request is now closed for voting, and your votes have been released back to use on other requests

  • Please note that transfer to the roadmap doesn’t guarantee implementation - some features may not proceed based on our assessment findings, however we will update this thread once a decision has been made.

Thank you to everyone who voted and contributed to the discussion. Your input has been invaluable in helping us understand the community’s needs and use cases for this feature.

1 Like