I don’t remember the history with LLDP - I will review. Its a good observation that its more important for network admins than the storage admins. Is it worthwhile to make the package available and allow admin to set-up via CLI?
SNMP improvements - can you expand on specifics?
(it is true that we’ve invested in the API to allow more complete remote control)
Graphite protocol - supported in CORE and CE
TrueCommand - Yes, it will be maintained until alternative non-cloud solution is available. The TrueCommand update to support Goldeye API is in the works. Goldeye API is fully versioned so that future updates are automatically supported.
I was mistaken about graphite or maybe I wasn’t - I remember there was a release of SCALE that could not export data to an external reporting DB like influx.
SNMP - it would be great if we could get more data, like temperatures etc. without falling back to IPMI. AFAIK lmsensors does that on Linux and can be integrated with SNMP.
Similarly there is a VM-MIB etc.
There is no such thing as too much reporting. Even if the data seems irrelevant at first - as Marcus Ranum put it: “The number of times an uninteresting thing occurs is an interesting thing.”
That’s why I invested a huge amount of time and effort into getting Netflow into my network, for example. Elastiflow is awesome.
Agree on preferring not to use IPMI… however, there are some stats where its the only good source
The two alternatives to SNMP are the graphite/netdata exports and the TrueNAS API. Why use SNMP over the other choices?
P.S: I helped get the 1st Netflow implementation out the door at cisco (1993?). That was a radical change to not rely on SNMP and design for performance.
Because the NMS based on SNMP are ubiquitous? I might have a wrong impression of enterprise infrastructure. We definitely run SNMP But we are not that large.
Ah … now I get where you are coming from. We are not that siloed
I manage “the data centre”. Layer 2, layer 3, storage, compute, … everything. We have one operations team and 4 software development teams. Operations provides all necessary infrastructure for development, back office, and hosting customers.
I use Observium. LibreNMS gave me weird values for memory usage specifically with FreeBSD hosts and although Adam Armstrong has a reputation for being difficult it’s a fine piece of software. That’s why I wrote the complete Observium on FreeBSD install guide.
No, no. It’s perfectly good. I just had that idea it had been removed from SCALE at some point. I actually like Grafana, and graphite plain text → influx → grafana works great.
Not that I knew. Observium does its own thing with a MySQL/MariaDB database for the data, already aggregated with RRDtool - there is no raw time series data here. You could theoretically use Grafana’s MySQL connector, but what then? There is no database schema documentation apart from the source code.
It’s cisco ISE we use it in the enterprise for very granular control for access of most every type of device on a network either using tacacs+ or radius. I have a feature request for this. You should be able to search, i answered most questions there.
LLDP is with LLDPd or ladvd a simple “fire and forget” service in Debian/Ubuntu. Preinstalling it with it’s system unit file disabled would be simple and have no impact on other installations.
I don’t understand why it was deprecated.
(I know, keeping it deeply configurable may use ressources, but using standard options should be able without further thinking).
(I was asked by our net admins to enable lldp where possible to better keep track of switch connections and enable easier debugging of LACP-errors if server are connected to wrong ports or lines are getting mixed up).
In the meantime, I got LLDP running on Goldeneye using a custom Docker app from the Official LLDPd Docker. Just use host networking, and add the required capabilities.
We use Cisco ISE here. It enables use of administrator logins with enterprise-controlled 2FA tokens, like SecurID, which isn’t currently possible with TrueNAS. +1 vote for RADIUS/TACACS+.
But we are not that large.