Some accesspoints (AP130 and AP230) are reporting: AP's exceed maximum number of IP sessions (98828) Is there a way to figure out where the sessions are going?

[bjorn]

Some accesspoints (AP130 and AP230) are reporting: AP's exceed maximum number of IP sessions (98828) Is there a way to figure out where the sessions are going?

[samantha_lynn]

Thanks very much for that output, that shows 4085 incoming LLC packets, divided by 120 seconds for the 2 minutes, that gives us an average of roughly 34 packets per second. This is over the threshold of the max we'd like to see per second, so that might be a sign of the issue causing those errors. Could we get a packet capture so I can check your traffic to see if we can find where the excess is coming from?

This guide reviews how to run a packet capture using Wireshark (alternatively, there is a built in packet capture feature now in HiveManager that doesn't need Wireshark or Cloudshark, but I'm still working on the guide for that. If you want to check it out, it's in the Tools tab)- https://thehivecommunity.aerohive.com/s/article/Packet-Capture-in-NG

Thanks very much for your patience, I'm sorry for all the different data grabs and tests, but I appreciate you working with me through all of this.

[bjorn]

Hi Sam,

Here you go (exactly 2 minutes) 🙂

Interface [eth0]

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

Inocming Counters

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

LLC: 4085; ARP: 1255; IP 8152

ICMP: 0; UDP: 7790; TCP: 119; GRE: 0; ESP: 0

HTTP: 0; HTTPS: 0; FTP: 0; TELNET: 0; DNS: 0; DHCP: 110; SSH: 4

Dropped: 9101

Outgoing Counters

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

LLC: 182; ARP: 151; IP 1263

ICMP: 0; UDP: 1134; TCP: 125; GRE: 0; ESP: 0

HTTP: 34; HTTPS: 116; FTP: 0; TELNET: 0; DNS: 13; DHCP: 0; SSH: 0

Cheers,

Bjorn

[samantha_lynn]

Yes please, we'd want to test during what would be considered normal business day traffic.

[bjorn]

@brian, the reason why we didn't use the alg sip enable is that our voip provider (yes we are using voice over wifi) doesn't recommend this

@Sam do i need to run those commands during the day (while there is traffic)?

[samantha_lynn]

Thanks very much for the tech data. Some notes on what I looked at/found:

CPU is not spiking

Checked for warnings related to the issue, none found

Reviewed the error messages in question, found quite a few, no further details

No evidence of a broadcast storm so far

If you could run the following commands, I'd like to check the incomming LLC count, but the AP's been up for 20 weeks so the counters would be pretty general at this point.

clear forward count int eth0

*let the AP run as normal for 2 minutes before running the next command, time it if you can because we need an accurate second count between these two commands.*

show forward count int eth0

Then if you can send me the output of that command, what we're looking for is the incoming LLC count and we'll divide that by 120 seconds to get an average packet per second count. We're hoping to see this below 30, above that we'll start seeing issues and then we'd want a packet capture to dig deeper in to where those packets are coming from.

Additionally, Brian's suggestion about running "alg sip enable" is a great one. In the event the TCP monitor function is not operating properly, this will get it back in line and might clear up those IP sessions when a TCP connection is closed, rather than leaving them there and filling up the logs.