I have a CN with no aggregations and ran lldpneighbors and then i ran it again and go t " lldpneighbors couldn't connect to the OpenLLDP transport socket. Is lldpd running?'

COnfig file oddness?

`[ERROR] in config file: invalid location_data_format '0'`

And /var/run/lldpd.sock can't be bound?

i never configured lldp*

Oh...

smartos just had it running

i figured it was supposed to just work.

I wonder if lldpneighbors attempts to run the daemon? `pgrep lldp` say anything?

253625

And `svcs -xv lldp/server` ?

Is there another command I'm suppoed to use to get ToR switch port number

(I'll note it's running on my no-aggr systems as well.)

State: online since December 15, 2022 at 03:39:27 PM UTC

no impact

I know it doesn't work over aggregations

SOrry.

but we are just debugging this 1 where we believe we had another cross connection

I just got up and was going to start testing this week's Triton.

No problem not a big deal

its all jbk fault :P

Anyway... `svcs -xv lldp/server` on both your local machine and any appropriate remote ones.

Smithx10 same here - lldpneighbors answers once - maybe there's some kind of rate limiting - or it's waiting for the next lldp packet

neuroserve: yea, looks like thats the behavior

Smithx10 but on some CNs/HNs it answers every time...

I think that a peer is sending it data that makes it crash.

I've seen it happen, but not consistently enough to track it down.

Probably Cisco

Ive got Cisco toR

ACI Nexus switches

restarting lldpd changes the behaviour...

Juniper here...

neuroserve: your using ixgbe?

nope - igb - oldschool

I've been dying to replace our lldpd, but the alternatives don't compile on illumos. I started writing one in rust, but I got hung up with it and didn't get very far.

Though, there is now rust_lldp, so maybe I should look into that again.

bahamat: can you send over the url please? I googled it and couldn't find it

ahh strange when I typed it exactly into google nothing popped up, but just lldp crate poped right up

Yeah, but docs.rs says it doesn't build, and there's literally no documentation for it.

yea, very minimal

maybe i should finish up my version :)

though it still doesn't solve the aggr issue, but it'd at least integrate with smf and other bits as needed

do we have a /dev/kmsg ?

no.

we DO have /dev/msglog though.

ooops, that's just for the console (but maybe that's what you need?)

What problem are you trying to solve Smithx10?

We got hit by the flapping interface again

So I was looking at go libs for parsing the last 15 seconds from it

found a lib github.com/euank/go-kmsg-parser

think I will just probably read /var/adm/messages

and look at the last timestamp *

Smithx10: sysevents?

Yeah, that's the supported interface. NOTE that we collapse repeated messages there, so you may wonder "why am I only seeing one" and then seeing something like:

Dec 13 23:41:05 neuromancer last message repeated 1 time

rmustacc: I'm using prometheus that come around to do a scrape every 15s

Is there a counter for a flapping interface, or would I have to subscribe to the events and keep that count myself

If it's flapping out long enough to make the NIC go "down" from IP's POV, it's possible `route monitor` may suffice.

Right now you'd have to keep the counter yourself.

possibly crazy/bad idea... there's a change from robj that was never done for adding an interface to generate ireports in the kernel.. i wonder if link notifications might be an appropriate use case for such a thing

(IIRC, the example there was for something like noting SAS link speed change)

jbk: I mean, we already have that part of it there.

We are already generating a sysevent.

So changing that to an ireport doesn't buy much.

can ireports be used with the fmd modules? it might be nice to be able to mark the interface as degraded or such if it's flapping too frequently (vs. having to scrape logfiles to find out)

It can subscribe to the sysevents?

hmm.. probably.. looks like there are modules that already do for other stuff

and fmd doesn't fork() after the initial startup

so don't have to worry about it deadlocking

next time I hit it, I should really file a bug since apparently no one has

to get all the details, but IIRC, if a thread tries to fork() while another is in a door call, it can cause a deadlock and unkillable process

OK. If you can write up some details, give me a shout and we can look at it.

so /var/log/messages isn't syslog lol

at least not 3164 or 5424