One of my clients has an SA540, which seems to be working okay, but while inspecting it today, I saw the below statistics. The RX Drop Pkts count concerns me. The statistic "shows the no of good packets received by a port that were dropped due to a lack of resources (e.g., lack of input buffers)" (text copied from the SA540 help screen).
Does this mean the appliance is being maxed out and is not up to the job? There are only 11 computers in the main office where the router is located, and there is an IPsec VPN to another office where only one worker accesses the main network through the VPN for RDP sessions on a server.
This is kind of scary if the SA540 is maxed out. I have another SA540 going to a client in a couple of weeks that is doing VOIP and data with 15 users and 4 branch VPN's. The specs would seem to indicate this appliance could handle that load, but now I'm not too sure. I would appreciate hearing from anyone (particularly from Cisco) with insight into this issue
Firmware Version: 2.1.18
After my initial post, I checked another client's SA540 and they are having the same issue with dropped packets. This client has about 30 computers on their network.
Firmware Version: 2.1.45
Message was edited by: Tony Lombardi to add second image of port statistics.
We are looking into this issue but would like to know if the packet drop is effecting any functionality in the setup?
Not sure what you mean by "functionality in the setup." Sometimes the console locks up, so that the router has to be manually restarted. That happens usually when failover is turned on. Right now, failover is turned off. Other than that, the appliance seems to be working okay except it's dropping packets according to the statistics screen.
Can you please provide more details on the router lockup? Is this issue always reproducible when failover is turned on? Can you please provide the topology and the type of traffic running through the device?
Can you also provide the dbglogs (please send a private message) if this issue is reproduced again.
Logs onto SA540 web UI and in the URL type: https://IP_address_of_SA500/scgi-bin/dbglog.cgi
where 'IP_address_of_SA500' – is the IP address of the SA500 router.
The three times the router was put into failover, it locked up with no access to the management console until it was restarted. Since then, firmware 2.1.45 was installed to try to resolve another issue the router was having. Because of the problems, the router has not been put back into failover mode; although all the configuration is there. It just needs to be activated.
The SA540 is on a small network. In my initial post, it was noted that there were about 30 computers. That was a low count. With network printers, servers (about 6), and mobile devices, the actual count is probably between 60 and 70. The network has a T1 to which a Netopia router is attached and IP 192.168.1.254 is assigned. It's sole purpose is a connection for the customer's email server. Verizon FIOS is the primary ISP for the network and Bright House (Road Runner) is the failover ISP once failover is reactivated. These connections are attached to the SA540 of course. The IP address of the SA540 is 192.168.1.1.
There are two HP switches (that's probably the problem ). I could not get to one of the two switches Sunday, but below are two screen shots of a statistics screen on one of the switches.
I have the log file you requested, but there does not seem to be a way to attach it to this reply. Please, either tell me how to attach the log or give me an email address to send it to.
I have send you an email with my contact information, please send the dbglogs to the email address.
Did you ever get to the bottom of your issue? I have the same device (recently purchased) and I am seeing the same issue with a high RX Drop Pkts count.
No, not really. We got into other problems and the dropped packets were never really addressed. It's still happening as you can see from screen images below from two of the appliances. I wonder if the statistics are simply packets rejected by the firewall due to policy infractions. However, Cisco techs with whom I talked did not indicate that was the case.
Thanks for the quick reply.
What I find strange is that no matter the load, it seems like the count increments by the same amount (6 or 7) during every Poll Interval.