cancel
Showing results for 
Search instead for 
Did you mean: 

Stale LLDP information?

Stale LLDP information?

bfrappier
New Contributor

I have a few AP650's telling me they're connected to the same port on the same switch (They may in fact all come through that uplink, but are definitely connected to another switch first)

 

I also have an AP30/ATOM unit that thinks it's connected to an HP 5412zl - problem is we've retired that switch quite a while ago.

 

Just curious what I can do to force this information to refresh, thanks!

17 REPLIES 17

bfrappier
New Contributor

The investigation continues.....

 

@Sam Pirok​ 

So it appears if there's any information in the "show lldp cdp nei" table, ECIQ will use that information.

 

If there's more than one entry? It seems to pick one at random.

 

If the "show lldp cdp nei" table is empty, it'll use the information from "show lldp nei"

 

@John Kern​ can you check both of those on your APs? I'm betting your CDP table is doing something weird.

 

 

I can probably just disable CDP on our switches and resolve this but I'm curious why the firmware reacts this way...

 

 

bfrappier
New Contributor

Also I just did the 10.0.r8 update and now the LLDP information is updated, but still incorrect LOL. One of the 650's thinks it is connected to the "WAN PORT" of a yealink T19P. We do have T19's here but I do not hve an access point plugged into any of them lol.

 

When SSH'd in it tells me the proper port/mac/etc.

 

edit: Actually after some poking around I've found what I think is the culprit. @Sam Pirok​ 

 

When I do "show lldp neighbor" it shows the correct device, but when I do "show lldp cdp neighbor" it shows me the incorrect (further down the chain?) information.

I did a "clear lldp table" and "clear lldp cdp table" to be sure and waited a few minutes.

 

show lldp neighbor shows me 1 neighbor, show lldp cdp neighbor shows me 3(first showed 1, then 2, now 3...).

 

What am I misunderstanding here?

 

And more importantly, can we get the cloud pages to show the LLDP information instead?

 

 

bfrappier
New Contributor

Unfortunately no. Sam does seem to be correct - the hpr/lpr files aren't making it up to the cloud for whatever reason.

 

But I wasn't able to get anywhere with support, and I'm told it's random when this is attempted to trying to get a packet capture is very difficult.

 

FWIW they all appear to have correct information if you SSH into them, it's just not getting uploaded.

 

I'm not sure why ECIQ is picking up what it's picking up (one of our core switches, and IP phone, etc....) but it's not getting it from the devices.

 

Have confirmed no egress filtering and even whitelisted our AP subnet, no issues that I can see.

w1f1n00b
Contributor II

I'm curious if you were able to resolve this, as I'm looking into why some of my APs are not reporting lldp info to ExtremeCloudIQ while others are. I'm specifically looking at AP550's all on 10.0r8 going to the same network switch. Some devices report lldp info some don't. When running the port test above I'm seeing similar results.

bfrappier
New Contributor

Thanks Sam. I'll go ahead and open a support case, because something is wrong with our CAPWAP IP for sure.

 

I'm getting the AP telling me it's only dropped a handful of heartbeats, strong connection to capwap, etc etc...but failing those tests to the server IP (I'm currently getting 34.202.197.27)

 

I did a quick test with a completely open server, portquiz.net, and the AP passes test tcp-service with flying colours on any port.

 

But when running it against the 34.xx IP, I get the failures. So I do not think it's out firewall or access point rules.

 

 

GTM-P2G8KFN