topic Re: Stale LLDP information? in Aerohive Migrated Content

Stale LLDP information?

bfrappier — Tue, 19 Nov 2019 22:49:24 GMT

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!

Re: Stale LLDP information?

samantha_lynn — Wed, 20 Nov 2019 02:49:04 GMT

Could you tell me where you're seeing the incorrect switch information in particular?

Re: Stale LLDP information?

bfrappier — Wed, 20 Nov 2019 03:05:18 GMT

In my 'default view' in the 'manage/devices' tab I've added eth0 LLDP Port #, sys-ID and sys-name columns

Here's an example:

Re: Stale LLDP information?

bfrappier — Wed, 20 Nov 2019 03:06:13 GMT

Re: Stale LLDP information?

samantha_lynn — Wed, 20 Nov 2019 03:09:02 GMT

Thank you for letting me know. Would you be able to send me tech data from one of the devices reporting an incorrect port? If you'd like to send this to me directly, my email address is communityhelp@aerohive.com.

Re: Stale LLDP information?

samantha_lynn — Wed, 20 Nov 2019 04:19:10 GMT

Thank you for that tech data. I'm seeing a lot of the reporting files sent from the APs to the ExtremeCloud IQ instance that are failing. For example: system: curl -F "filename=@/tmp/l7_report/206C8A0505000546.hpr" -m 900 -k -f --basic -u VHM-GOBMTTMN:********************* "https://va2.extremecloudiq.com:443/afs-webapp/l7report/80314/" "VHM-GOBMTTMN" failed to http to server,rc=8960(35)

You can see that it's failing to http to the server, which indicates an issue with a firewall or content filter. The reporting files (.lpr and .hpr files) need to get to the ExtremeCloud IQ instance for it to report accurate information. I would recommend checking any firewalls or content filters to see where these packets are getting caught up.

Re: Stale LLDP information?

bfrappier — Wed, 20 Nov 2019 04:35:01 GMT

Interesting….we don’t do any filtering for our APs at all, actually. And no egress filtering otherwise.

Are there a few URLs I can test against on my laptop somehow maybe?

Re: Stale LLDP information?

bfrappier — Sun, 24 Nov 2019 08:23:59 GMT

Or better yet, specific commands (I assume that same CURL attempt won't be valid) I can test on a few APs to see what's happening?

Re: Stale LLDP information?

samantha_lynn — Mon, 25 Nov 2019 22:12:25 GMT

Sorry for the wait here, I haven't been able to find any URLs you could test with, you might want to open a case with technical support to troubleshoot further. This command will test TCP ports:

exec _test tcp-service host <HiveManager IP> port #

Re: Stale LLDP information?

bfrappier — Tue, 26 Nov 2019 00:53:36 GMT

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.

Re: Stale LLDP information?

w1f1n00b — Tue, 25 Feb 2020 04:03:32 GMT

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.

Re: Stale LLDP information?

bfrappier — Tue, 25 Feb 2020 04:41:19 GMT

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.

Re: Stale LLDP information?

bfrappier — Tue, 25 Feb 2020 05:47:07 GMT

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?

Re: Stale LLDP information?

bfrappier — Tue, 25 Feb 2020 05:49:22 GMT

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...

Re: Stale LLDP information?

samantha_lynn — Tue, 25 Feb 2020 06:09:10 GMT

Thank you for sharing those details, I'm going to see if I can get someone from our engineering team to weigh in here on why certain entries are picked over others when there are more than one.

Re: Stale LLDP information?

bfrappier — Tue, 25 Feb 2020 06:24:07 GMT

Thanks. Here's a few snippets if it helps.

BURL_BALLROOM#show lldp

LLDP general information

----------------------------

Enabled: yes

Number of LLDP neighbors: 1

Max number of LLDP neighbors: 64

Sending LLDP packets interval (seconds): 30

Sending a holdtime value (seconds): 90

Sending a required power value (watt): 25.5

BURL_BALLROOM#show lldp cdp

CDP general information

----------------------------

Enabled: receive only

Number of CDP neighbors: 14

Max number of CDP neighbors: 64

CDP is currently showing 14 neighbors.

LLDP:

BURL_BALLROOM#show lldp nei

LLDP neighbor table: Total number = 1

--------------------------------

Incoming Port: eth0

Chassis ID(mac address): 18e8:2922:xxxx

Port ID(locally assigned): 0/6

Hold time(seconds): 120

Port description: 0/6

System name: HAI-XXXX

System description: EdgeSwitch 48-Port 500W, 1.9.0-lite, Linux 3.6.5-03329b4a, 0.0.0.0000000

System capabilities: bridge, router

Enables capabilities: bridge

802.1 port VLAN identifier: 1

Management address:

IP address: 10.x.x.x

CDP:

BURL_BALLROOM#show lldp cdp nei

CDP neighbor table: Total number = 14

Incoming interface: eth0

Device-ID: T19P_E2805EC015BF2C

Device addresses:

Device addresses number: 1

IP Address: 10.x.x.x

Holdtime: 164 sec

System Capabilities: Host

Version:53.82.0.20

Platform: T19P_E2

Port-ID (Port on Neighbor's Device): WAN PORT

Incoming interface: eth0

Device-ID: T48S805EC00FF661

Device addresses:

Device addresses number: 1

IP Address: 10.x.x.x

Holdtime: 157 sec

System Capabilities: Host

Version:66.83.0.35

Platform: T48S

Port-ID (Port on Neighbor's Device): WAN PORT

Incoming interface: eth0

Device-ID: T48S805EC0325D32

Device addresses:

Device addresses number: 1

IP Address: 10.x.x.x

Holdtime: 154 sec

System Capabilities: Host

Version:66.83.0.35

Platform: T48S

Port-ID (Port on Neighbor's Device): WAN PORT

Incoming interface: eth0

Device-ID: T48S805EC0333434

Device addresses:

Device addresses number: 1

IP Address: 10.x.x.x

Holdtime: 147 sec

Re: Stale LLDP information?

w1f1n00b — Tue, 25 Feb 2020 23:22:10 GMT

Looking at two more APs where AP1 is reporting lldp info to ECIQ and AP2 is not, the only difference I can find is that AP1 is reporting 2 lldp neighbors (the same switch on both Eth0 and Eth1) and AP2 is reporting 1 lldp neighbor (switch on Eth1).

These are both configured for Eth0-Eth1 Redundant and patched to the switch with two cat6a cables.

If I run - sh lldp cdp both report "Enabled: no"

Not sure if this is the same root issue you're having or not but figured I'd share since it's at least related.

Re: Stale LLDP information?

w1f1n00b — Wed, 26 Feb 2020 23:15:45 GMT

Ok. I have to clarify something here and admit my mistake. In looking through my column picker I've now included the lldp sys name for Eth0 and Eth1. So it's not that some APs aren't sending the information. All APs are sending lldp info. my bad.

My problem is related to having both Eth ports in use and how the AP handles redundant config. Some APs are "up" on both interfaces while others are only up on one. I'll start a new thread for this topic.

Sorry again for confusing the discussion.

I will add though, @Brian Frappier have you considered disabling the cdp option in the network policy>additional options>network services>LLDP/CDP to see if that at least works as a work around?